An oracle enables permissionless blockchains like Ethereum to access data from the outside world feeding Smart Contracts which can then execute specific actions within supported digital applications (dApps).
Without oracles, blockchain applications would be limited to local data and the huge growth we’ve seen in areas like DEFI wouldn’t be possible.
In this article, we’ll explain:
- What is a blockchain oracle?
- What are the different types of oracles?
- The problem that oracles face
- Common oracle use cases
In just over a decade blockchains have provided the foundation for a trillion-dollar cryptocurrency ecosystem but their design has a fundamental flaw. Without data from the outside world, described as off-chain, they would be very limited in the type of applications they could support, on-chain, verified and recorded within the blockchain.
Blockchain oracles solve that problem by pulling data from external sources enabling supported applications to offer crypto users a wide range of services with precision and accuracy.
Though blockchains require off-chain data, oracles aren’t the source. They simply provide a means to query, verify and authenticate external data sources provided via API Feed and then pass that data securely and reliably on-chain.
Given that oracles are a conduit, they can function in several different ways varying by the direction of information flow and source of the data.
The most common kind of oracle is software that aggregates data already available on the internet and feeds it to a Smart Contract, such as price data for cryptocurrencies.
Some blockchain-based applications need to reference data from the physical world, which can only come through a piece of hardware such as a sensor or scanner. This could include data on weather, traffic or physical sales.
Sometimes the source of data can only be provided via a human, who feeds the data into an oracle application and signs it cryptographically. An example could be in-game data from a low tier tennis match powering a betting dApp.
Each type of oracle simply delivers data to a destination, but the manner and direction can vary.
Input oracle – The most common type of oracle fetches off-chain data (from the outside world) and feeds it into blockchain applications.
Output oracle – In some cases, an oracle can push data in the other direction, from a blockchain (on-chain) to an external service. This could be because a Smart Contract has a function to trigger a bank payment when a certain condition is met.
Cross-chain oracle – Though enabling blockchains to exchange data without the outside world is hugely important, the same is true of data sharing between blockchains. Cross-chain oracles enable this, though they face the difficulty of reconciling different consensus methods.
Computer Enabled – In some cases, an oracle can act as a random number generator for a Smart Contract with the outcome confirmed on-chain before the dApp uses it. A good example is a lottery draw where the oracle acts as a VRF – verified random function – the equivalent of the ball machine you might have seen in televised lottery draws.
Though there are many ways for oracles to access information and feed it into Smart Contracts, they risk becoming a single point of failure for blockchain applications and open up the potential for data manipulation. This challenge is known as the Oracle Problem and has no easy solution.
Data feeds aren’t unique to blockchains; almost all centralised digital applications use API feeds but require some kind of trust-based authentication to confirm data validity.
The most apparent way oracles could verify data would be to replicate the centralised approach to accessing data in the off-chain world, but this immediately challenges the decentralisation nature of blockchains. Even with checks and balances, getting data from one source produces a central point of failure.
A centralised oracle is open to error and downtime and is a target for anyone that would gain from being able to manipulate the feed.
The more popular alternative to centralised oracles is to use a decentralised oracle network (DON) working from several sources incentivised to provide accurate data.
One of the most popular decentralised oracles is Chainlink which we can use as an example to illustrate the way blockchain applications use oracles.
A truly Decentralised Oracle Network needs to combine multiple independent oracle node operators and multiple reliable data sources.
Chainlink Price Feeds attempts to solve the issue of a single point of failure by ensuring decentralisation across the three layers of the oracle — the data source, node operator, and oracle network levels.
One of the most puzzling things to newcomers to Bitcoin is where its price comes from? There is no single truth for its price, just a collection of independent marketplaces for buying and selling Bitcoin – cryptocurrency exchanges – each arriving at a price based on demand.
Sourcing accurate pricing is a problem for any service that wants to reference an exchange rate for trading between Bitcoin and US Dollars, the most popular trading pair. Which exchange should they reference for the price, and to what extent should/could they rely on that one source of information?
This is the service that an oracle, like Chainlink, provides. Chainlink will reference a minimum number of Nodes, each providing a BTC/USD price. The Nodes are paid for their service in LINK – the native token of the Chainlink ecosystem – but also have to stake LINK as a kind of bond which provides a financial incentive to submit accurate information.
The Chainlink system takes a median price across all the Nodes and feeds that to its clients. Inaccurate Nodes lose their stake and are replaced by alternatives.
Chainlink Price Feeds underpin billions of dollars of activity across diverse applications. Still, it is just one of many decentralised oracles, each taking a slightly different approach to solving the Oracle Problem.
Having established what a blockchain oracle is, how they function and the challenges they present, we can look at some practical examples to put all of this into perspective.
DEFI has emerged as one of crypto’s most significant use cases, with the market capitalisation of the biggest DEFI coins touching over $170bn at the end of 2021. DEFI allows lending and borrowing, swapping and yield generation, all of which rely on real-time price data provided by oracles.
There are many fully decentralised sportsbooks, casinos and prediction markets, each with its own oracle needs. Sportsbook and prediction markets need results data for grading, while casinos and lotteries need provably fair random events. These can all be provided by oracle services and confirmed on-chain.
Gaming is providing the next decentralised frontier under the banner of the Metaverse. Though these are new types of virtual games, players can own what they create. When money is on the line, players want to be sure that the game isn’t rigged, so oracles enable verifiably random game-play experiences.
NFTs are barely a few years old but have already seen significant innovation. One example is generative art, representing a unique collaboration between an artist and an autonomous system fed with random inputs from an oracle.
NFTs can also use external data from oracles – such as the time of day or temperature – to dynamically change. A character could wear sunglasses when it is sunny or change its background to night mode.
Though DEFI has grown at a phenomenal rate, so have hacks that drain millions of dollars of value in minutes. Smart Contract auditing is a partial solution, but like in TradFi there is a growing demand for insurance products within DEFI. For a Smart Contract to establish the appropriate premium for funds locked within a protocol or group of protocols, they need to know the value of assets set via an oracle.
Input oracles could also pull in data from hardware sources – satellites or sensors – or software sources, such as legal or public registries, to establish the basis for a claim to be triggered. The process could also happen in reverse, where a condition within a Smart Contract or across different chains could trigger external insurance payments.
Chainlink is just one of many providers of decentralised oracles, each with a slightly different approach to solving the oracle problem. In truth, all solutions include some sort of compromise or vulnerability.
The sheer complexity of Chainlink’s three-layered solution is an issue as it creates a broad attack surface for bad actors to find a way to compromise the data it is feeding into a blockchain.
The way Chainlink ensures the integrity of its data has also been criticised for failing to provide a meaningful economic incentive to do the right thing and not collude to provide false data. Its tier of data-submitting Nodes is kept honest by an additional layer of Nodes.
The question is ‘Who is policing the second tier?’ which becomes a recursive problem. This conundrum is just an extension of the broader question around how to scale blockchains but retain security and decentralisation – the blockchain trilemma.
Setting aside the question as to whether oracles are truly decentralised, you have to consider the, more straightforward issue of cost.
For the highly liquid BTC/USD market, there is evident demand and willingness to pay the fee from an oracle but is the oracle system practical or even justified at the micro-scale?
In Ancient Greece an oracle was a person believed to be able to act as a portal, enabling the Gods to speak directly to the people. They were tremendously influential, guiding everything from politics to military strategy.
The modern blockchain equivalent of ancient oracles holds an equally important position, bringing information to closed blockchain domains from the off-chain world. In complete contrast to their Greek counterparts, blockchain oracles must be able to prove their accuracy and independence as well preserve the decentralised way blockchains work to justify their usefulness.