What are Oracles? Blockchain Technology Explained

Oracles are entities which source and secure external data for blockchains, enabling smart contracts to interoperate with external systems.

The Greco-Roman oracles of antiquity were said to have special powers, enabling them to act as divine translators to enlighten the common people as to the inclinations of their gods. In the world of Web3 and blockchain-related technologies, oracles perform similar functions, but rather than having to trust their words, blockchain oracles back up their data with proof. That is, blockchain oracles are data-driven and secured by cryptographic primitives that maximize transparency and verifiable security. 

To put it more plainly, oracles are entities that serve as bridges from blockchain ecosystems to external data sources. Oracles call on web APIs or other external sources for fresh data since smart contracts don’t perform these functions natively. Public blockchains record transactions and maintain public copies of the blockchain ledger’s history. New transactions are confirmed in batches, or blocks, using a variety of consensus mechanisms used by their node participants, and smart contracts enable frictionless, trustless transactions to be executed and recorded in the public ledger.

Decentralized oracles add another layer of complexity to this ecosystem by enabling new sorts of hybrid smart contracts which request off-chain data for inputs in order to ‘know’ when to execute. Oracles therefore facilitate interoperability between the smart contracts and the physical world, not to mention the legacy networks which make up global financial markets. 

Through the interplay and composability of various networks, the usefulness of blockchains and Web3 dApps is greatly enhanced. Decentralized blockchains provide secure and transparent ledgers and histories, smart contracts facilitate complex interactions, and oracles bridge it all to the real world. While it seems simple enough, several problems arise as networks become more complex, like the potential for oracles to become single points of failure, creating havoc if erroneous or stale data were to make its way onto these deterministic and often immutable protocols. 

The potential that a single point of failure could create issues within smart contracts and the blockchains they run on is a major conundrum which has been discussed for quite some time now. It is sometimes known as the Oracle Problem or “Oracle Dilemma,” resulting from the difficulty in addressing the dilemma without making performance sacrifices in the design and architecture of oracle protocols.

The Oracle Dilemma

Simply put, smart contracts execute based on inputs. If they only rely on the consensus of other nodes maintaining an internal ledger, this can be a source of strength since the verification of inputs can be done in a decentralized manner. ‘Trusting’ external oracles complicates the situation since the inputs cannot be verified ‘on-chain’ by consensus, but are transmitted from external sources, vetted by oracles. As such, the data inputs from oracles must be correct if they are to be used for practical purposes like ID verification, IoT sensors, insurance companies, not to mention finance and gaming. 

Blockchains are decentralized by nature, and thus boast security partly by reducing the possibility of single points of failure. By having distributed network nodes, the risk of one or many becoming corrupted would not compromise the system. However, this advantage could be negated by funneling data through centralized oracles before making its way onto blockchains. However, without access to the external data that oracles provide, blockchains, dApps, and smart contracts would have far fewer use cases. This is very clearly a problem if the technology is to scale. 

Oracles naturally hold significant influence over blockchains and dApps since the data oracles provide determines how their smart contracts execute. Consequently, having to trust these data feeds to uphold the integrity of the system removes the advantages of blockchains and their distributed networks by centralizing the data feeds. Thus, if not properly addressed, rudimentary oracle protocols effectively negate the trustlessness of decentralized networks and even pose dangers if pristine data is not kept constantly refreshed with minimal downtime.

These characteristics and their tradeoffs will require some unpacking in order to comprehend the oracle problems waiting to be solved through innovation. First, the authenticity and security of the data needs to be verified just the same as blockchains, through decentralized rounds of consensus on newly formed blocks. By the same token, the data needs to be kept updated frequently so as to not become stale. 

Just as with blockchains, certain issues crop up as the network scales, meaning that as oracle networks become more decentralized, conducting rounds of consensus begins to take longer, and users find that their transactions do not go smoothly if the network is congested. This not only results in degradation of performance and usability, but affects refresh rates and thus the increased likelihood of slippage occurring if stale data is used to execute smart contract transactions.

Furthermore, the cost of constantly refreshing data, the ability of an oracle network’s nodes to maintain the network uptime and the throughput necessary to pull off such difficult feats without failure pose significant challenges to developers. After all, it is fair to declare that financial markets have never slept since the trading of digital assets began. Oracles must therefore create critical redundancies to safeguard against network manipulation, downtime, future scaling and congestion issues, and black swan events.

If smart contracts may be originated, canceled, or executed night and day, and those contracts make use of data from external sources, then the data feeds themselves cannot be corrupted if the smart contracts are to function as intended and in a just and fair manner. That is, if Jill agrees to trade with Jack 1 Ethereum (ETH) for 2 ounces of tokenized, digital gold (PAXG), then both the prices of Ethereum and gold must be carefully verified by oracles and broadcasted to the protocol or dApp on which Jack and Jill have formed their smart contract. Any deviation from market spot prices regarding either asset would leave one or both parties feeling disappointed in the end.

To illustrate the point, imagine Jack and Jill making their agreement to trade assets while ETH’s market price was $4,000 USD and 1 ounce of gold at $2,000 (x2 ounces). Consider if the oracle nodes, or their underlying blockchain network, suffered performance issues during a time of market volatility and the price of gold went from $1,900 to $2,100 and then back to $1,900 in early morning trading hours. 

If ETH had remained roughly stable at a price of $4,000, Jack and Jill would expect to find their trade had executed as per their agreement. However, since our example oracle network failed to report the sudden spot price volatility of gold in a timely manner, the trade never executes and the protocol fails to function as intended. This could arguably be characterized as an extraordinarily minor and inconsequential example of what might happen when oracles fail to perform as needed. 

Going by the current market cap of all crypto assets, there are literally trillions of dollars on the line, and more in leveraged borrowing. If capital is wrongfully liquidated, the losses could be catastrophic, and the ripple effects might be felt financially, not to mention harm the reputation of blockchains, smart contracts, and related Web3 technologies. Consequently, the oracle dilemma must be solved before Web3 completes its disruption of global finance and finally crosses the chasm from pioneers and early adopters to early mainstreaming.

Classification of Oracles

Blockchains need to interact with external data in a variety of ways, meaning oracles function in different ways to best serve those requirements. Hybrid smart contracts, or those which make use of off-chain resources for functionality, not only need to handle inputs and outputs from blockchains, but may also facilitate cross-chain communication as well as provide computation and randomization functions. 

Of course, oracles can perform one, several, or all of the following functions, and therefore oracle classifications should not be seen as mutually exclusive. Therefore, let the following represent an overlapping Venn diagram of oracle functionality which either intersect, or are interrelated:

Input Oracles

Input oracles are perhaps the most commonly known variety, as they fetch and validate external data for use by hybrid smart contract protocols. By using distributed networks of nodes, oracle protocols typically ping out aggregate data from APIs and other web sources, and those aggregates are further aggregated in some fashion in order to arrive at a consensus number with an acceptable margin of error.

Output Oracles

Supply chain management, Internet of Things systems, and banking networks might all find use cases for dispatching data to signal the completion of an event. For instance, output oracles would permit shipping companies to verify a constant temperature for sensitive goods throughout a given journey. Moreover, bicycle rentals or car-sharing apps can use input and output oracles to signal that a payment has been made and to unlock the rented transportation.

Cross-Chain Oracles

Over time, the amount of blockchains and smart contract users has grown to impressive numbers. It is unlikely that any one blockchain will be used universally around the world. Consequently, blockchains will inevitably need to communicate with one another in order to interoperate. Not only do cross-chain oracles enhance the liquidity of Web3 protocols, but they also serve to disincentivize competition and tribalism amongst various blockchain communities and incentivize productive cooperation instead. 

Cross-chain oracles basically monitor the activities of various blockchains and report conditions to other blockchains or token bridges. Token bridges, of course, allow for crypto assets native to one blockchain to be traded as ‘wrapped tokens’ on other blockchains. Oracles verify that double-spending or other manipulative activities do not occur without detection. Reserve audits can also be used to verify traditional, off-chain assets as well, which will be covered in further detail below.

Compute-Enabled Oracles

Oracles perform other functions aside from fetching and validating external data, such as generating verifiable computations of randomness. This is often done when randomness needs to be computed off-chain, known as verifiable random functions (VRFs) due to network throughput limitations or economic disincentives. VRFs are fair and transparent methods of generating random numbers for use by on-chain smart contracts. For instance, non-fungible tokens (NFTs) are often minted in sets of 10,000, with each user minting their NFT randomly. The use of oracles to generate these VRFs ensure that the minting process is random, fair, and demonstrable via mathematical algorithms.  

Oracles can also act as ‘software bots’ to automate the operations of smart contracts when certain events take place. For example, oracles can wait until your yield farming harvest reaches a specific dollar amount before withdrawing funds or moving them to a different protocol to maximize yields. Oracles can also securely authenticate data veracity using zero-knowledge proofs to maximize user privacy without sacrificing data security or speed in exchange.

Decentralized Oracles’ Use Cases

DeFi & Proof of Reserves

Plenty of centralized and decentralized crypto protocols require oracles to access data from external sources. Exchanges, money markets, and other protocols which utilize digital assets use oracles to determine the reserves backing specific stablecoin assets, not to mention borrower collateral in the case of decentralized lending. Other assets which are pegged to external market spot prices use oracles to keep prices updated, and automated money markets make use of oracles to fill limit orders using price aggregates from oracles.

Enterprise/Supply Chain Management

Oracles also create opportunities for enterprise brands and supply chain managers to connect front and backend systems to blockchain networks of their choice. Of course, many will opt to use bespoke, private blockchains which will inevitably have practical needs requiring cross-chain interoperability and communication, facilitated by oracles. 

This is especially important since the cost of making systems interoperable have historically been measured in high prices and security risks of sharing sensitive data or providing access to internal processes. Consequently, major economies of scale will be able to deploy their assets more efficiently and reduce counterparty risk since oracles secure data by leveraging powerful cryptographic primitives.

NFTs & GameFi

Oracles also enable hybrid use cases for non-fungible tokens, such as dynamic NFTs. NFTs are totally unique tokens minted on blockchains which can be exchanged between wallets, and cannot be divided or exchanged for anything else in kind. Dynamic NFTs may also change, dynamically, based on external events or achievements such as current weather, the score of a sports game, or unlocking of a video game achievement. 

As previously mentioned, compute oracles generate verifiable randomness which can be assigned to NFTs at the time of minting, like fur color, hat style, or background color. Compute oracles can also select random winners competing for exclusive NFT airdrops or other special releases. Blockchain gaming and eventually metaverse protocols will use compute oracles to generate randomness for creating verifiably fair competitions, discovery of rare items, and other chance encounters.

Healthcare & Insurance

Insurance protocols will use input and output oracles to verify the occurrence of insurable events during the claims process by leveraging web APIs, satellite imagery, IoT-style sensors, police and medical reports, and legal documentation before triggering payouts. Applications in agriculture, auto, home, flood, fire, and health insurance companies will find use cases for hybrid smart contracts which leverage oracles to make it all possible. Fraud detection, claims processing, and auditing departments will soon discover new tools at their disposal and more resources to deploy towards high-return endeavors.

References

1. Caldarelli, G. (2020). Understanding the blockchain oracle problem: A call for action. Information, 11, 509.
2. Caldarelli, G., & Ellul, J. (2021). The blockchain oracle problem in decentralized finance—A multivocal approach. Applied Sciences, 11(16), 7572.
3. Collins, P. (2020, 2 Sep.). What is a blockchain oracle? Better Programming. 
4. Southurst, J. (2020, 8 Sep.). Chainlink exploits lead to ETH losses—again. CoinGeek.

Related Articles

• Web3 Oracles: Finality & The Cost of Latency
• KYC Requirements and Web3: A Role for Oracles
• What is Miner Extractable Value?

Learn More

• Cryptographic Proof: Oracles & Stablecoins
• The Promise and Perils of Blockchain Voting
• What are Smart Contracts?