Explore → AirnodeHow does Airnode work?
Airnode is a serverless oracle node implemented with a set and forget philosophy that brings off-chain data from APIs to on-chain smart contracts.
It consists of two parts:
- The off-chain Airnode (“the node”) that is self-hosted or deployed as cloud provider functions (AWS or GCP).
- The on-chain protocol contract AirnodeRrpV0.sol. This is often referred to as the oracle smart contracts.
Airnode is designed with mechanisms that eliminate both on-chain and off-chain concerns of API providers. The set-and-forget framework of Airnode is all about its ease of implementation.
For smart contract developers Airnode is a tool to utilize data from Web2 APIs within smart contract functions. The ease and flexibility of deployment means it can be utilized within the product development cycle as data requirements arise.
Technical Characteristics of Airnode
Statelessness
Third-party oracle nodes typically track blockchain and request state, either from the chains memory or database. This approach has disadvantages:
- The database becomes a single point of failure with costly redundancy mechanisms
- In the instance of on-chain anomalies there is difficulty keeping chain and node synchronized
- Potential debilitating bugs from highly stateful applications
Due to this traditional third-party oracle nodes demand professional node operators who need to be available around the clock in case anything goes wrong. This is simply not realistic for oracles if they are to scale to tens or hundreds or thousands of API Providers.
However, there is an alternate. As the blockchain used by the oracle node already keeps the state on its behalf, there is no need for the oracle node itself to keep its state. Duplicating the state also creates twice as many points of failure.
Therefore, the oracle node should depend on the blockchain node to keep its state. Thus, Airnode is designed to be stateless.
Fully-serverless stack
Although serverless functions are better known for scaling automatically even with extreme concurrent usage, Airnode uses it for different reasons:
Serverless functions have the benefit of being stateless: This means any problems encountered during Airnode invocation will not persist in the next. Being able to quickly reset provides greater robustness against bugs from Airnode, APIs or Ethereum nodes.
Serverless functions are fully managed: They provide the closest possible experience to the set-and-forget philosophy.
Serverless functions are priced on-demand: Airnode does not require major concurrent usage, resulting in cost-efficiency and even let the user stay within free tier AWS, GCP limits.
Additionally, bare serverless functions are easy to port across cloud providers (e.g., using Terraform Framework), especially when their cloud provider-specific dependencies are limited.
Note
Due to being stateless Airnode is able to reset itself quickly and easily, providing a solution for most potential issues.
Approach to security
For an optimal, hands-off user experience, Airnode should utilize fully managed services whenever possible. To allow this to be done securely, the node is designed defensively.
There are two external parties that Airnode interacts with:
- APIs: Although Airnode is designed for first-party oracles, it considers serving data from third-party APIs as a valid usage scenario. In this case, calls made to all APIs are contained in separate serverless function invocations so that they cannot induce node-level failure.
- Blockchain nodes: Similarly, using blockchain nodes that are run by third-party service providers is considered as a valid usage scenario. To ensure maximum availability, Airnode uses all providers simultaneously (and not through a Quorum-based consensus or behind a load balancer), which is possible thanks to its unique stateless design. The interactions with each provider are contained in a separate serverless function invocation so that a malicious provider cannot induce node-level failure.
For Airnode cloud hosting is recommended over hosting on-premises. This is due to the superior availability of serverless functions, and also for their set-and-forget qualities. As a precaution, redundancy on multiple cloud providers can be provisioned easily and virtually at no cost thanks to the fully-serverless design of Airnode.
In addition, the protocol is implemented in a way that a blockchain service provider cannot tamper with the parameters of a request, but only deny service. Note this is not the case with alternative solutions, as they treat the blockchain service provider as a trusted party.
Learn more
Read more about how Airnode works in the Airnode reference section.
Blockchain (RPC) Providers
Airnode requires access to a blockchain RPC node to:
- Listen for request events from the blockchain to the oracle
- Trigger transactions to fulfill requests from an API Provider to the smart contract
To avoid disruption to oracle operation, Airnode has been designed to allow the usage of multiple RPC providers simultaneously. Each RPC provider is treated as individual, meaning all providers must be malicious for Airnode operations to be disrupted reliably. Additionally, using multiple Ethereum providers helps achieve the highest possible availability.
Airnode operates on free RPC tiers
An Airnode that receives no requests consumes fewer than 3,000 calls per day which is included within the free plans of RPC providers such as Alchemy, Infura, or Pokt.
Airnode Configuration Files
The Airnode is defined by a file name config.json. It is the central element feeding data to beacons, the components that supply on-chain dAPIs with data behind the scenes.
- See Understanding Airnode to learn how Airnode is defined by
config.json. - See Deployment Files to view the available configurations fields for
config.json. - See config.json to view an example file.