Oracles – The Internet of Blockchains

Just”knowing thyself”is not sufficient for a smart platform blockchain. Oracles are critical middleware that connect blockchains to the real world unlocking the full potential of platforms chains.

Their use is ubiquitous across decentralised applications in all new themes such as decentralised finance, interoperability and supply chain, and their use will grow as these themes play out.

In this issue of the Bridge, we discuss how blockchains’ inherent inability to connect to the real world limits their use and how oracles provide the solution by acting as middleware to their connection to the world. We discuss “the oracle problem” and why it is imperative that oracles follow a decentralised model.

We find that oracles are pervasive in their use across decentralised applications and find use throughout all key themes and implementations of blockchain technology such as decentralised finance, interoperability and supply chain. We also cover key oracle projects that are enabling the growing ecosystem of decentralised applications today.

A blockchain can only read the information that is present on itself. It is unable to access any information outside of it or any metadata about itself. Blockchains function like a computer that is not connected to the internet and can only read the data available on it. This closed architecture minimises vulnerabilities and ensures the blockchain’s security, but it also limits its use.

For blockchains used only to settle value like Bitcoin, Litecoin, Ripple, this limitation is not an issue. For blockchains designed to run smart contracts and applications like Cardano, Ethereum, Polkadot, to name three, this is a severe limitation. The ability to interact with the outside world and to use information is key to unleashing the full power of decentralised applications. Without it, any decentralised applications (dapps) built on these platforms will be limited to only information available on the blockchain. For example, consider the case of a prediction market for whether the price for ETH will exceed, say, USDk 5 at any point in 2021 or not. No information on the Ethereum blockchain records ETH price in USD so the prediction market would not be able to resolve whether the condition has been met or not. Similarly, since smart contracts are executed separately and independently at every node, for an application that leverages random numbers, every node may resolve a different random number and achieve a different result (see figure 1). Multiple results would stop the block from achieving finality as consensus would not be achieved. Further, it breaks down the deterministic quality of blockchains – the ability to rerun all the transactions and get to the same result.

Oracles provide solutions to the problems mentioned above. They bring off-chain (outside the blockchain) data, to the blockchain so various applications and smart contracts may access it. Oracles connect blockchains to the real world, the internet, and each other.

In a multiple platform blockchain world, one or many decentralised oracle solutions will connect them to the internet and each other allowing information to be shared and accessed by the multitude of applications built on these blockchains. If blockchains were computers, oracles would be the modems, allowing them to interact with the internet and with each other (see figure 2). Oracles also help resolve problems like the random number problem suggested above. Instead of the computing nodes separately generating random numbers, the oracle runs the random number simulation and publishes it on the blockchain. The computing nodes will use this published number to achieve the same result. In this way, block finality is achieved, and the deterministic nature of the blockchain is preserved.

There are two broad types of oracle blockchains:

• On-chain oracles act as bridges between blockchains, allowing blockchain information to be read and used by other blockchains. For example, a multi-chain decentralised exchange (DEX) aggregator will need price feeds from the decentralised exchanges running on Ethereum, Cardano and other blockchains to fetch the best price available. For this purpose, an on-chain oracle may run through the DEXes on Ethereum, Cardano and others to fetch the best price for the aggregator. An on-chain oracle may also be one dapp providing oracle services to another dapp. For example, Uniswap (a decentralised protocol for automated market making) natively knows the price between any two assets listed on the platform through its liquidity pool. Any dapps that need the price relationship between the two assets can use this data.
• Off-chain oracles act as middleware connecting blockchains to the non-blockchain world. For example, suppose the shipping journey of a product is being recorded on a blockchain. Here, the off-chain protocol will connect to the sensors reading the NFC (Near Field Communication) tag of the product through its various hops and communicate it to the blockchain where it is recorded.

They may also be classified in other ways:

• Inbound vs outbound oracle – Inbound oracles transfer information from outside the blockchain to the blockchain. An outbound oracle will do the opposite, moving data from the blockchain to outside it.
• Software vs hardware vs human – Software oracles will pull data from the internet, other blockchains and dapps, APIs and so on. A hardware oracle may connect an Internet of Things (IoT) device reporting real-world data to the blockchain. A human may also act as an oracle as in the case of Augur’s prediction market where a user may vote that a particular outcome has occurred by staking their asset on it.

Public blockchains are designed with decentralisation as one its central philosophies, and they are not subject to a single point of attack risk. Using a centralised oracle to feed data defeats the purpose of a decentralised blockchain. A malicious actor need not attack the nodes of a blockchain if it can compromise the oracle it uses to input incorrect data onto the blockchain. Continuing from the previous example, if a malicious actor in control of the oracle has made a bet that the price of ETH will remain below USDk 5 for 2021, it will never allow the oracle to send a price higher than USDk 5 to the blockchain for the smart contract to resolve correctly.

A malicious actor is not necessary for centralised oracles to fail to do their job correctly. We have seen that price data from one source may get affected by a flash crash (see article) leading to a cascading effect if more applications trust it.

Therefore, to mitigate this problem, decentralised oracles solutions aggregate data from multiple sources and use a consensus mechanism to minimise the risk of misreporting. The operators that feed the data to the aggregating algorithm are incentivised to report correct information and punished for incorrect information. For every correct piece of data reported, the contract, or user requesting the data, transfers some value to the protocol that splits it among the operators that provided it. Operators lock certain value on the protocol; if consensus is reached for which an operator’s data is rejected, some pre-decided value is slashed from the operator’s stake. As with blockchain consensus, as long as 51% of the participants are reporting correctly, the oracle reports the correct data.

To understand the ubiquitous use of oracles, we explore a few blockchain use-cases.

Decentralised Finance

DeFi applications have extensive data needs to be able to deliver financial solutions efficiently. For example, Maker Protocol that lends out collateralised DAI relies on price data from oracles to determine how much DAI to issue per unit of cryptocurrency collateral. It also uses oracles to ensure that the DAI already issue is always sufficiently collateralised.

Interoperability

Interoperability protocols may have their own oracle solutions or may rely on existing oracles to allow free flow of information between different blockchain protocols to ensure coordination. For a multi-chain decentralised exchange (DEX) aggregator, information must flow freely to provide its users with the best price.

Supply chain

One of the applications of blockchain technology is to record the full history of a product to be verified independently by its consumer. For example, this may be used to independently ensure that a product’s origin is from a particular country or to ascertain its carbon footprint. To achieve this in a fully automated manner and to ensure no conflicts, an oracle needs to be used in conjunction with a reporting mechanism like Near Field Communication (NFC) tags to feed a product’s journey through its supply chain onto the blockchain. Any interested party can later independently verify it and be confident of its accuracy.

Prediction markets

Prediction markets allow users to make bets on the outcome of an event. For example, the result of a football or cricket game or the winner of an election. An oracle is required to report an event’s outcome, so the winning bettors may be paid as the blockchain independently cannot know what real-world event has occurred.

Gaming / Gambling

Gaming relies on randomness to provide a level of luck and excitement to the players. Games may use randomness provided by oracles to resolve the chances for loot drop rate, miss and hit rate, and critical hit rate and other similar game mechanics. For unique drops, oracles can also verify the number of items in existence using NFT (non-fungible tokens) and confirm their historical drop rate. For gambling, players can individually verify that the deck of cards, dice roll, spin or any other mechanic used is verifiably random and how it has behaved historically.

ChainLink Network (LINK)

Chainlink is the leading decentralised oracle solution with almost all large DeFi projects relying on its data feeds. It is an off-chain oracle with a network of independent node operators that gathers and delivers data to its middleware application. The middleware application aggregates and combines it into single data output and delivers it to the blockchain to be read by smart contracts relying on it.

Chainlink network is blockchain agnostic, and developers can modify the core software to connect to any blockchain. It is currently widely used for Ethereum-based dapps, and the LINK token on Ethereum platform is used for payment of services by the users and will be used to bond by the operators. As more smart-contract based blockchain platforms grow operational, the LINK token may be added to other platforms to provide oracle and cross-platform services.

For a more detailed analysis of the Chainlink project and the LINK token economics, please follow the link (no pun intended) to the Digital Investor’s February edition – Chainlink Investment Thesis.

Band Protocol

Band Protocol is an on-chain oracle that runs on an independent Cosmos-based blockchain called BandChain and runs through smart platform blockchains. It allows for developers to write custom oracle scripts to fetch data to use in their dapps. BandChain uses a Delegated Proof of Stake consensus mechanism, and its 100+ validators fetch the queried data which is first published on BandChain and then on the requesting platform chain. Similar to Chainlink, validators are paid in the native BAND token for delivering data, and they have to stake these tokens so the any misreporting may be penalised. The turnaround time for a data request to be delivered is about 6 seconds as the block time for BandChain is only 2 seconds. Since BandChain is an independent chain, it does not suffer from network issues on the requesting chain like slow block time or high network fees.

The Graph

The Graph is an outbound oracle that indexes and collects blockchain data to be read and displayed in a user-friendly manner. It aggregates and indexes blockchain data by processing all the blocks. This allows it to deliver data through APIs which otherwise would not be easily accessed.

Developers or “curators” create applications that query the blockchain for specific data that may be of interest to the user. The node operators or “indexers” collect this data from every blockchain block and index it to be delivered to the user. For this service, they are paid by the developers of the app. The users of the application have to pay the “indexer” and “curator” to use their app and data. Typically, the developer for the application on the Graph is pulling information from their own dapp on the blockchain and presenting it to their users so that they may be able to make the best decision for themselves.

Simply speaking, it acts as an open-source search engine for blockchain data, with incentivised operators providing indexing and storage services. Applications built on it can visualise blockchain data for the user to understand and make a more informed decision.

For example, Uniswap’s information page (see here) uses The Graph to pull pair analytics, top pairs, transaction data, most liquid pairs, etc. It provides an intuitive front-end for the users to analyse and transact.

Other Oracles

Other than the projects covered above, any data generated by one app may be used by another. For example, Uniswap (a decentralised protocol for automated market making) natively knows the price between any two assets listed on the platform through its liquidity pool. This data can be used by any dapps that require price data between the two assets. A lending dapp may use price data to ensure that it has sufficient outstanding collateral against all loans.

We find that oracles are pervasive in their use across decentralised applications and find use throughout all key themes and implementations of blockchain technology like decentralised finance, interoperability, supply chain, and so on. We also cover the basics of crucial Oracle projects that enable the growing ecosystem of decentralised applications today.