Blockchain Oracles — Part I of II
In this article, we are going to explain why we need blockchain oracles and the general oracle problem and its use cases. Then we describe the terminology around blockchain oracles and how they work.
Last but not least, we present examples of different blockchain oracle networks and provide a list of links for additional reading.
Why do we need blockchain oracles?
Smart contracts are the key concept behind the Ethereum platform or more generally speaking blockchain 2.0 — the second generation (after Bitcoin) in the evolution of blockchain technology, which is the foundation of most use-cases today.
Smart contracts rely on deterministic triggers to execute their code. These triggers can originate from a user account/wallet (e.g. by sending funds to the contract) or from another smart contract (via so called traces or internal transactions). The code can never proactively transact on its own.
This results in a need for validated external information for the code to be reliably triggered and executed. Validated in this case means that the information is accurate and does not depend on a centralized sourcing process, thereby avoiding one single point of failure. This is very important, because the whole ecosystem of blockchain revolves around the concept of immutability and trustless interaction through decentralization. As decentralized systems are only decentralized to the point of their weakest link, connecting an oracle with a single point of failure to the blockchain would arguably cause complete loss of decentralization.
What is the blockchain oracle problem?
Practical example of the oracle problem in decentralized finance (DeFi)
To illustrate this with a practical example, let’s consider bZx.The protocol enables individuals to borrow and lend cryptocurrencies. Imagine you would borrow ETH. At any point in time, when you want to hand back the tokens, the bZx protocol needs to know how much they are worth to ensure a fair price for you. Commonly the price feed from a decentralized exchange (DEX) is used as a data source. The issue with this is, that the DEX price feed is vulnerable towards price manipulation attacks.
You could, for example, use part of the borrowed ETH to buy another asset listed on the DEX and the bZx protocol. Meanwhile, you would use the rest of your loan to pump the price of the asset (this is possible if the trading volume is low enough and the size of your loan high enough), then post it as collateral into the bZx protocol to receive a new ETH loan, which is then worth more due to the artificially increased price. Finally you pay back the first loan with the newly acquired one and take home the difference as profit. This has happened in the past and got the “hackers” a profit of roughly 600.000$ (learn details in this medium article). Now the question is: how can we ensure that this behavior is impossible?
Use case examples of the oracle problem
This challenge mentioned above is not limited to decentralized finance (DeFi), but is very relevant to a variety of different scenarios not only related to financial products.
- Insurances regularly lose millions in profit through fraudulent reports. If the payouts are tied to objective real-world events such as wind speed for a hurricane insurance, or flight delays, they can be validated and reported to the blockchain by oracles. Check out Etherisc, who has been the first team working on blockchain insurance use cases.
- Or consider another example: FOAM provides a decentralized location service that can serve as an oracle for proof of location (e.g. shipment of in a supply chain) to trigger payments, instead of relying on GPS as a single point of failure.
- Decentralized prediction markets like Augur open up endless possibilities for betting on literally anything. These markets also rely on oracles as a bridge from the real world to the blockchain to be legitimately settled.
These mentions only capture a small subset of all possible future applications of blockchain oracles but are illustrative enough to point out the great significance of the underlying challenge often called “the oracle problem”.
What is a blockchain oracle?
The solution to the above outlined problem is to use blockchain oracles as a source of information. Contrary to some common interpretation of the word, in the blockchain-space oracles do not make predictions about the future but report events after their occurrence with the goal to provide an objective reality of what actually happened in the real world.
BlockchainHub defines blockchain oracles as “[…] services that send and verify real world occurrences and submit this information to smart contracts, triggering state changes on the blockchain.” Note that “real-world occurrences” can also be blockchain events that reside on a different blockchain than the consuming smart contract.
Oracles bridge the on-chain blockchain world with the off-chain world by interfacing external data providers. They may also implement distinct measures of validation to ensure reliability of oracle operators / network participants.
Blockchain oracle terminology
If you are new to blockchain in general or specifically oracles, differing terminology across resources can make it hard to follow. This also shows in the above definition, as “oracles” mentioned there can point to oracle nodes or oracle networks /-network providers.
To address this issue, a brief description of the different parties involved follows:
- “Oracle network provider” is one of the terms that lies behind the word oracle. In this case the platform or infrastructure provider that hosts various nodes and validates the information reported by them is meant.
- “Oracle node” or simply “node” is the term to describe an entity that reports the off-chain data to the oracle network. The node is run by its oracle node operator. As in the previous example, often the term oracle is used interchangeably.
The plain term oracle seems most suitable for the latter node entity that queries the external source and publishes the data by writing it onto the blockchain, thereby executing the two major points that solve the oracle problem.
How do blockchain oracles work?
The provided definition combines the validation of the data sources with the process of submitting the information onto the blockchain. To better understand — and more accurately reflect the technical nature of blockchain oracles — the two components “acquisition of validated data” and “writing it on-chain” can be thought of separately.
Writing the data on-chain is straightforward: once the information is received by the oracle smart contract, it will be made publicly available via a function call. Technicalities such as the update frequency or data types are use-case-specific and can therefore vary significantly.
But the important part is: how can one ensure that the data written on the blockchain is legitimate?
There are various ways of implementing validation of the information that is reported by oracle node operators as participants of an oracle network. Most of the time oracle network providers opt for a mix of measures that prevent inaccurate data from being written on-chain. But validation does not solely lay in the hands of oracle network providers. Node operators and consumers of oracle information can also implement ways to increase the accuracy of the data they provide/receive. The following paragraph describes the main instances of such validation measures.
Reputation and Payments
If an oracle node operator does deliver good results constantly, their reputation increases. This can be tied to larger payments for the provision of data and serves as one of the basic forms of incentives in oracle networks.
Multiple data sources
A simple method to reduce the risk of wrong information is for node operators to use an average over aggregated results of multiple data sources. That way only if the majority of data sources or the node operator itself were compromised, false data could be written on-chain.
Multiple oracles
An oracle network, or a consumer of oracle information can decide to rely on multiple oracles to reduce the risk of erroneous data or node outages. It is far less likely to have the majority of oracles be malicious or unresponsive. Although if all oracles were to rely on the same or highly overlapping data sources, this form of hedging would provide insignificant benefits.
Staking / Slashing
Contrary to the common use of the word, staking in this case does not mean earning interest on provided liquidity. It means that oracle node operators are required to put tokens at stake to be lost (slashed) in case of malicious behavior. This serves as a negative incentive and is arguably one of the most promising mechanisms of trust in oracle node operators.
Trusted execution environments (TEEs)
Put very simply, TEEs allow applications to be executed in a separate part of the main processor of a computer. This allows for protection against subversion by other processes (integrity). Other parts of the operating system will not be able to read its data, code or state (confidentiality) while the application itself is still able to read and write memory outside of its separate part. Running oracle services in TEEs can therefore add an additional layer of security minimizing the risk of corruption. However, state of the art TEEs still come with vulnerabilities (for reference please see Source_1 and Source_2) and should thus also be considered only as an additional source of security rather than a stand-alone principle.
As a consumer of oracle information, it is vital to accurately assess the risk that can be taken by choosing either one or multiple oracles as sources of truth — and balance it against the costs and efforts of operation.
Examples of blockchain oracle networks and providers
For reasons of length and current practical adoption we will focus on “oracle as a service” in this example section. For other types of oracle networks/providers please refer to some of the examples mentioned before (e.g. FOAM).
Chainlink
Chainlink aims to create a “highly generalized oracle framework where users can create any oracle design pattern to retrieve and validate data in a highly secure and reliable manner”. This is achieved by building a trusted marketplace for consumers of oracle information and oracle node operators where Chainlink node smart contracts function as middleware and solve the oracle problem. The validation part is tackled mostly through aggregation of pricing data from different sources via multiple nodes and positive incentives for good performance in form of LINK payments to node operators per fulfilled data request. Currently the aggregation process resides on-chain, but Chainlink plans to implement off-chain aggregation in the future. Staking/Slashing (see above) will also be implemented in the future to further increase reliability. Later in this article, we will use Chainlink’s oracle process as an illustrative example of how the technical implementation can be done.
Around Chainlink’s services, a thriving ecosystem of oracle related organizations has emerged. One concrete example is oracle node performance made visible through on-chain analysis (Chainlink Oracle Reputation). Other entities provide Chainlink nodes-as-a-service (https://www.linkpool.io/) or an Oracle market (https://market.link/). On the market, node operators compete for jobs by offering different levels of security guarantees, functionalities, and off-chain data connections.
Chainlink is actively supporting the community with a grant program.
Witnet
“The Witnet protocol aims to create an overlay network that connects smart contracts to any online data source in a trustless, decentralized manner” (Witnet). Witnet achieves this by hosting a distributed network of nodes referred to as witnesses that earn WIT tokens as a reward for delivering web information to smart contracts. A significant amount of randomly chosen witnesses converge to a single truth via a consensus algorithm. Witnesses also mine transactions in the network. The probability of each witness to be assigned requests or to mine new blocks is directly tied to its past performance. To avoid centralization towards older nodes or exit scams, every 90 seconds (each block) a redistribution of reputation between all active nodes is conducted.
Provable
Provable, formerly branded Oraclize, “[…] is the leading oracle service for smart contracts and blockchain applications […]”. Instead of using some consensus mechanism to validate data of several sources, provable aims to prove that the data fetched from the original source is “genuine and untampered”. This way, no trust in provable itself is needed. The provable engine leverages TEEs and related technologies to provide upon so called authenticity proofs — documents that are returned together with the fetched data as proof of legitimacy.
Do you want to learn more about blockchain oracles?
Here are some more articles about the topic:
Medium — Comprehensive Overview
Blockchainhub — Quick Definition + Overview
Coinreview — Concise Overview
Stackexchange — How do oracle services work under the hood
Our oracle node at Anyblock Analytics
Anyblock is a long serving Chainlink node operator since summer 2019, and we also provide blockchain data across different networks via our Anyblock Index.
Many smart contracts on the Ethereum Mainnet rely on off-chain data that resides on other blockchains. Specifically for bridging the various side chains with the Ethereum Mainnet, our API serves as a data source and is queryable on-chain via our oracle node.
Furthermore, we are happy to announce that we have added Bitcoin and Litecoin (and soon Tezos) as additional blockchains to our data API, which can then be added for further cross-chain oracle use cases.
Part II — Chainlink Price Feed Oracle Process and more!
If you’d like to dive deeper into the world of Blockchain oracles, we invite to read the second part of this article where we explore the “Chainlink Price Feed Oracle Process” and share some of our experiences and tools for node operators!
Interested or questions?
Freddy Zwanzger
(Co-Founder)
freddy@anyblockanalytics.com
+49 6131 3272372
Originally published at https://www.anyblockanalytics.com on August 19, 2020.
