If this is your first time learning about the ACES project, feel free to read our intro post here.

This release is an expansion and improvement to our existing listener protocol, providing high quality features that will support a robust blockchain service ecosystem. This release also includes deployment of stake-based listeners for ARK and Ethereum, which you can begin using immediately to build services. We will be deploying two additional listeners for Bitcoin and Litecoin alongside our release of services in the coming weeks.

Services can be built leveraging the ACES listener data on a stake-based subscription basis. You may not need to download, sync, nor store as much blockchain data on your servers if you are using public listeners. The required stake will start at 100 ARK.

The motivation behind authenticated listeners is that blockchains are typically very large. Running full nodes of any blockchain can be expensive and also cumbersome because of the requirement to sync and store the data. In order for those running listeners to have incentive, there needs to be a reward mechanism. We have implemented and deployed an authentication approach for API registration that allows providers of listener data to receive rewards.

Listener Authentication through ARK

API access will require registration through the ARK blockchain. API keys are used by blockchain services to receive listener data and will be associated with the ARK address that registered. In order for your ACES listener API access to be enabled, the ARK address that is registered must hold at least 100 ARK for mainnet, or 10 ARK for testnet.

We have also added a feature for subscription-based listener fees so independent providers of listeners can be directly compensated for providing blockchain listener services. The subscription-based listeners create a special address for prepayment for listener registration. The wallet is managed by the listener application and depleted over time, and can be filled up as much or as little as the service provider desires. Consumers and developers can elect to use either the stake-based listeners or the fee-based listeners.

For the ACES hosted listeners, we chose to implement the stake-based implementation over direct fees. Utilization the listener network is completely free for those with a stake in the ARK Ecosystem. Service providers without a stake in ARK can pay for listener data through other fee-based implementations.

We will have listener deployment guides available for the community for each blockchain listener we build. Our set up uses Amazon Lightsail which makes launching a server and adding extra storage space very easy. The cost for the major blockchains is approximately $80/m per server at the time of this post.

The stake-based implementation that we are using allows services to charge much lower fees to their customers, since they will not need to pay for data from listeners and do not need to download nor store the blockchains. While $80/m is not a huge expense, it could be a deal breaker for small hobbyist service operators. Economies of scale are introduced by allowing the existence of listener-specialists. We would expect to have many more service providers than listener-specialists. The monthly cost of running a service could be as low as a few dollars a month for all blockchain services from a provider. The low cost for hosting services will result in a robust blockchain service ecosystem.

Here are some examples of how you can use the listener API authentication to subscribe to events.

1. No HTTP Basic auth credentials sent:

In this example, the response shows that authorization is required.

{

"code" : "authorizationRequired",

"message" : "HTTP Basic Authorization required."

}

2. Register an account by giving a user ARK address and getting an API key (inactive by default until ARK stake is verified and ownership confirmed):

This creates a response that shows that authentication is pending. You also receive your API key that can be used in service applications. The response includes instructions on how to activate the authentication. In this example the user must send a payment of the desired amount to the payment ARK Address. Sending a transaction from [ARNJJ…] to [AbUSp…] verifies the user address. The funds added to [AbUSp…] are used for fee payment every 24 hours (the actual value charged is set in the application.yml config file).

{

“id” : “p7FCGo3fJPXOXveFWAbB”,

“status” : “pending”,

“apiKey” : “7tqf3x0v4bMZgI8hBsx8prVFU1EOUERlOEkUX3I0”,

“userArkAddress” : “ARNJJruY6RcuYCXcwWsu4bx9kyZtntqeAx”,

“paymentArkAddress” : “AbUSp1ceHkkahtA97xgspZgy9WJST2JJXa”,

“createdAt” : “2017–12–31T06:26:43.807Z”,

“hasEnoughStake” : false,

“hasPaidFee” : false,

“userArkAddressVerified” : false,

“arkStake” : 0,

“paymentAccountAmount” : 0

}

3. Use the Listener API:

The above example uses the apiKey to make a subscription request to the Ethereum listener with the callback URL of the service application. It is also specified that the application requires two confirmations before accepting the received data. The below response confirms the request. This portion of the listener service will begin to make more sense when we release the BTC/ARK service in the coming weeks, which is built to consume external listener data.

What’s next

The listener authentication protocol sets the ground work for ACES blockchain services. Our next major release will include implementation of a two-way BTC/ARK service that receives its data from an ACES listener. This will be an open source project, as always, and can be run independently by the community.

You can continue to follow our development and get involved through our Github at https://github.com/ark-aces

Reach out to us on Reddit at www.reddit.com/r/arkecosystem or on Slack arkecosystem.slack.com in the #ACES channel.