Smart contracts running on blockchain networks have significant potential to increase efficiencies and reduce transactional costs across an array of industries. Smart contracts effectively minimize counterparty risk and provide transparency, but they still face several limitations to their capacity.

The growing need for external data flowing into blockchains and, by extension, smart contracts has led to debates and innovation around Oracles. Oracles are data feeds from external systems that feed vital information into blockchains that smart contracts may need to execute under specific conditions. The growing need for oracles represents the continued expansion of blockchain systems into practical and real-world use cases, where accurate data is crucial.

However, oracles represent third-party data feeds that may need permission from external entities. Further, correctly implementing a decentralized oracle network comes with multiple challenges. So how can oracles be trusted and become the decentralized networks of information that blockchains need to bridge the gap between on-chain and off-chain interaction?

Smart Contracts and Oracles

The concept of smart contracts was proposed by Nick Szabo in the early 1990s, and his projections for their implementation and use are astoundingly accurate relative to their existence today.

Read: Crypto Profiles: Nick Szabo, The Quiet Cryptocurrency Pioneer

At a high-level, a smart contract is a computer program comprised of code that defines its function and state. Smart contracts are typically referred to as operating on blockchains, where they autonomously and transparently execute under specific conditions that are met over a distributed network. Blockchains transfer their immutability to smart contracts since, once they are committed to the chain, they cannot be changed.

Smart contracts have trustless execution where the need for intermediaries is removed, and traditional transactional frictions are minimized. Their ability to execute based on hard-coded parameters is exceedingly useful in a variety of scenarios such as legal agreements and automated payment systems.

Despite their clear benefits, smart contracts are limited to a walled garden of on-chain data and information within the blockchain. This limits their capacity to interact with the real world and execute based on conditions outside of the blockchain network they exist on. Enter oracles.

Oracles

The notion of oracles — even decentralized oracles — has been around for years and continues to fuel debate about how to implement them and whether they can be trusted.

Oracles retrieve and verify external data for blockchains and smart contracts through methods such as web APIs or market data feeds. The type of data required by smart contracts can include information on price feeds, weather information, or even random number generation for gambling. Leveraging oracles consists of querying the data source for specific information and subsequently connecting to that source to interface between the blockchain and the data feed. As a result, smart contracts can execute based on the particular information flowing from the data feed.

Data feeds in real-world markets and web APIs are usually not deterministic like blockchains and smart contracts. Oracles act as a bridge that can digest external and non-deterministic information into a format that a blockchain can understand and execute particular conditions with. Oracles can even be used for N-of-M multi-signature transactions to reach consensus on which transaction to sign, in relevant scenarios.

Oracles form the basis of platforms like Augur, which is a decentralized prediction market. However, Augur is more representative of a complex oracle itself that functions as a data feed based on the “Wisdom of the Crowd” where participant behavior effectively acts as the data source. Augur also utilizes oracles for reporting the correct result to prediction markets with an incentive structure driving honest reporting.

There are several forms of oracles including:

Hardware Oracles

Software Oracles

Consensus Oracles

Inbound Oracles

Outbound Oracles

Hardware Oracles are sensors integrated with tangible physical objects. Primary examples would be in supply chain tracking with the use of RFID tags for feeding data like environmental conditions of products to the blockchain.

Software Oracles are the most common form that pull data from third-party sources such as web APIs and can include real-world information like flight statuses and weather data.

Consensus Oracles represent a step towards decentralized oracles and rely on aggregating data from several oracles with proprietary methods for determining their authenticity and accuracy.

Inbound Oracles reflect “if this happens then do that” scenarios associated with software oracles such as “if this price is met by an asset, then trigger a sell.”

Outbound Oracles allow smart contracts to send data to sources outside of the blockchain network they exist on and are also software oracles.

The potential ability of oracles to bridge off-chain and on-chain data as an interface between traditional networks and blockchain networks has important long-term ramifications. However, the inherent problem is that these oracles are from centralized points of origin that typically require third-party permission. Additionally, the obstacle of authenticating oracle data is where trust-minimized systems like blockchains and traditional trust assumptions clash.

The Oracle Problem

Jimmy Song provides an excellent breakdown of the fundamental problems of oracles and smart contracts. The Oracle Problem is defined as the security, authenticity, and trust conflict between third-party oracles and the trustless execution of smart contracts. The digital world needs to know about the physical world.

Oracles retain an enormous amount of power over smart contracts in how they are executed because the data they provide determines how the smart contracts execute. Therefore, data feeds from third-party sources give that data substantial influence over the execution of a smart contract, removing its trustless nature as part of a decentralized network.

Specifically, in the context of tethering physical assets to the blockchain, oracles are not capable of providing trustless verification that ownership of an asset such as a house is actually transferred to the new owner, even if the new owner holds a token representing ownership on the blockchain. Possession in a smart contract does not always transfer to possession in the real-world, thus removing the killer application of smart contracts, trustless execution. This is a result of the smart contract needing to rely on some third-party verification of the events in the real world, in the form of an oracle.

The limitations of oracles in regards to blockchains and smart contracts are well-documented with some substantial research into how to effectively implement them. Platforms tackling the oracle problem include Delphi, Oraclize, and ChainLink. Essentially, these platforms are predicated on building decentralized oracle solutions by leveraging consensus-based oracles, decentralized marketplaces, and novel methods of authenticating oracle data.

ChainLink

ChainLink provides an intriguing decentralized solution to authenticating the data from oracles and the subsequent output data of smart contracts. ChainLink identifies that problem with centralized oracle feeds as a single point of failure and offers a solution through a “middleware” comprised of a decentralized oracle network. Importantly, ChainLink identifies and authenticates data prior to it becoming a trigger for a smart contract.

Read: Beginner’s Guide to Chainlink

ChainLink’s on-chain interface consists of oracle nodes that reply to data queries made by contracts. The on-chain interface is comprised of 3 components:

Reputation Contract

Order-Matching Contract

Aggregating Contract

The Reputation Contract uses a proprietary method for storing and tracking oracle service provider metrics.

The Order-Matching Contract takes a service level agreement (SLA) and logs the data parameters of the SLA while simultaneously taking bids from oracle providers.

The Aggregating Contract collects oracle provider’s responses and calculates the final collective result of the initial ChainLink query.

Aggregating the oracle data provided by multiple sources helps ensure a more accurate view of the data supplied, reducing the reliance on a single entity (oracle). Oracle provider metrics are also fed back into the reputation contract for managing oracle accuracy through an incentive-driven reputation system.

The use of the SLA is vital for the oracle selection process. Users requesting oracle data can identify explicitly the parameters and inputs they are looking for as well as how many oracles they would like to use. The reputation of oracle providers can also be added into the SLA proposal.

From a broader perspective, ChainLink is effectively functioning as an off-chain listing service with an on-chain oracle authenticity/aggregation product. Oracle providers are collectively managed through a participating reputation system, and automated order-matching services facilitate the selection of oracle providers for specific data needs. Providers can also submit bids for SLA’s based on their requirements.

A pool of oracle providers is eventually selected by ChainLink who are notified of the task required. Providers (which are off-chain) subsequently report the requisite data on-chain. The resulting data is fed into the aggregating contract where a weighted answer is calculated. The weighted response is returned to the specific smart contract function as the trigger for the contract’s relative execution. Further, the provided data accuracy from the oracles is fed into the reputation contract as part of the larger reputation system.

ChainLink has a native token that is used for compensating oracle providers that supply accurate information. The architecture of the platform also consists of oof-chain components including external adapters, subtask schemas, and a core node software for interfacing with the blockchain.

Despite ChainLink functioning as a middleware, it is a decentralized oracle intermediary that functions as a tool for accurately interpreting and allocating external data to blockchains. Users ultimately have to trust that the ChainLink model works correctly, but its distributed oracle sourcing and subsequent aggregation of data are profoundly more effective methods of authenticating data than directly trusting external data feeds themselves.

Conclusion

For blockchains to have a sustainable impact in practical applications and various industries, they need to be able to interface accurately and reliably with real-world data. Achieving this with oracles is difficult and presents many challenges. However, significant progress has already been made on this front, and the future connectivity between blockchains and external data feeds will represent a major leap forward for the technology.