ARK Core 2 Technical Update Series — Webhooks

For ARK’s 3rd technical blog post we will discuss Webhooks, a new primary component of the upcoming Core v2 release.

Webhooks implementation is a realization of Ark Improvement Proposal — AIP15.

A Webhook is an API concept that’s growing in popularity. As more and more of what we do on the web can be described by events, Webhooks are becoming even more applicable. They are a useful and resource-light way to implement event reactions. A Webhook (also called a web callback or HTTP push API) allows an app to provide other applications with real-time information. A Webhook delivers data as it happens (providing data immediately) as opposed to typical APIs where you poll for data very frequently in order to get it real-time. Webhooks are much more efficient for both provider and consumer. The only drawback is the difficulty of initially setting them up.

Webhooks enable ARK blockchain app developers to listen to blockchain events in a simple manner (by subscribing to events and waiting for callbacks). Polling is just wasteful and inefficient for both the client and server side. On average, 98.5% of polls are wasted and increase the workload on the server, making Webhooks much more efficient.

Webhooks are an integral part of ARK Core v2 due to the ever growing ecosystem and traffic increase. They will allow for traffic reduction and greatly optimize overhead.

For users, Webhooks are a way to receive important information when it happens, rather than repeatedly checking for data and receiving nothing useful in return. Webhooks have tremendous potential to automate and optimize tasks. For starters we selected the following events you can subscribe to via API v2 call (see photo below).

List of current possible event subscriptions

In a case study by Zapier (a SaaS company connecting thousands of applications together), monitoring the hook polling process, 30 million calls were polled, but only 460,000 of them where efficient with actual data changes (1.5% efficiency). After switching to Webhooks they received/executed only 540,000 calls in the same time period with 100% efficiency.

Did you notice the reduced workload? According to a survey (https://zapier.wufoo.com/reports/polling-or-webhooks/), the majority of developers preferred Webhooks for receiving changes instead of polling.

Best practices and happy developers with efficient tools are all part of our motivation to deliver ARK Ecosystem as a platform — while providing a stable and efficient base to build blockchain apps.

With ARK’s new API v2 you will also get Webhooks capability, that will call and deliver data based on event conditions.

How do I subscribe to Webhook events ?

How can you subscribe to a Webhook? Well simply put, it is an API v2 call where you specify the event you want to listen to, and your endpoint parameters where the event data will be received. In this way you get:

1. Mechanism to store subscriptions.
2. Mechanism to modify subscriptions via API.

All this is related to your secure token and allowed access (read below) that is configured based on the node parameters.

Defining Webhook with conditions

Example of response from previous Webhook

The secret is the token is verified on your end every time a Webhook is sent. It has a header like:
X-Hook-Token:
de9ad9b17f4c8c0ce3633e7b3b243771b950e592aab92b48de3e5f5ed3d7205b

The client has to verify that this header is equal to the secret you received when you created the Webhook. If not the request will be rejected.

Subscription parameters, that can be defined together with the subscription calls

What about security?

By default Webhooks will be disabled. Node owners will configure their node to enable Webhooks, define their own security token and allowed/whitelisted IPs. In this way the node owner is responsible for securing, maintaining and providing Webhooks services to listeners and applications. It is also recommended to whitelist its use when enabled to a limited number of IPs. Managing a high number of Webhook registrations is exponentially CPU and memory consuming.

Use cases

AIP15 has been designed to handle business logic needing to inspect blockchain in a transversal way:

• Exchanges can record hooks to listen for incoming transactions for their customer receiving accounts, without having to repeatedly poll them. They will also become much more responsive to users depositing funds.
• Delegates will be able to handle a fleet of nodes with powerful auditing Webhooks and trigger a forger to connect to the healthiest node in case of a fork.
• ARK ACES will be able to leverage Webhooks to have a lighter and more responsive way to handle contract executions.
• In the future of SmartBridge use, mutual nodes that are securing 2 or more ARKchains will be able to listen painlessly to each other.
• Make your node in your own language (overwriting the public interface for instance), but still relying on the same mechanic for maintaining consensus with network.

There will be plenty of room for improvements, for instance Webhooks for confirmed transactions (e.g., after user defined number of blocks).

Conclusion

Overall, developers get easier tools to build blockchain apps and end-users get more blockchain apps delivered with event-based and secure integration points. Ultimately this promotes widespread adoption and easier integration with legacy systems (e-commerce, supply chain management, IoT event subscriptions) and many more. It is a win-win situation on all sides!

In the next blog post we’ll scratch the surface of ARK Core v2's heart and provide a bit of insight into the workings, technologies and improvements made over v1.