Oracles retrieve real-world off-chain data to the blockchain to allow smart contracts to perform reliable and consistent computations. Oracles consist of a smart contract and an off-chain node. Centralised oracles rely on a single trusted data source, whereas decentralised oracles gather data from multiple sources.
Oracles and off-chain data
Most real-world business processes will need to use a combination of on-chain and off-chain data. Imagine that you have deployed a smart contract that has a function to re-evaluate a portfolio against a defined model. The function will need asset balances (on-chain) and asset valuations (which may be off-chain).
Ethereum and similar blockchain networks are deterministic: computations must always produce the same results given an initial state and a particular input.
In order for that to be the case, any data used in those computations must be on-chain and available to all nodes. Only then can it be guaranteed to be immutable and reliable.
Oracles solve this problem by taking information from off-chain sources and storing it on the blockchain for smart contracts to consume. Once stored, this information is unalterable and publicly available, so nodes can safely use it to compute state changes without breaking consensus.
How oracles work
An oracle is made up of an on-chain smart contract and one or more off-chain nodes.
The oracle contract is the on-chain component for the oracle service. It listens for data requests from other contracts, relays data queries to oracle nodes, and broadcasts returned data to client contracts. This contract may also perform some computation on the returned data points to produce an aggregate value to send to the requesting contract.
Upon receiving a new query, the oracle contract will emit a log event with details of the data request. This notifies off-chain nodes subscribed to the log, who proceed to retrieve data defined in the log event.
The oracle node is the off-chain component of the oracle service. It extracts information from external sources, such as APIs hosted on third-party servers, and puts it on-chain for consumption by smart contracts. Oracle nodes listen for events from the on-chain oracle contract and proceed to complete the task described in the log.
Oracles come in different types, including immediate-read, publish-subscribe, and request-response.
(De)centralisation
Oracles can be centralised or decentralised.
Centralised oracles are controlled by a single entity with a single (off-chain) source of truth. These are useful where there is a trusted source of the data, but requires trust and lacks availability (single point of failure) with no incentive for correctness.
Decentralised oracles are designed to overcome the limitations of centralised oracles by eliminating single points of failure. A decentralised oracle service comprises multiple participants in a peer-to-peer network that form consensus on off-chain data before sending it to a smart contract.
Decentralised oracles attempt to achieve correctness of data using different approaches. This includes using proofs attesting to the authenticity and integrity of the returned information and requiring multiple entities to collectively agree on the validity of off-chain data.
Authenticity proofs are cryptographic mechanisms that enable independent verification of information retrieved from external sources.
Decentralised oracles deal with discrepancies in information retrieved from multiple off-chain sources by either allowing users to vote on the accuracy of the data or by using a Schelling-point mechanism where responses are aggregated into a single mean or median value after which nodes are rewarded or punished according to the extent to which their responses align with or deviate from the aggregate value.
The role of Tokenbridge
Tokenbridge software often fulfils the role of on oracle node as it brings off-chain data into the blockchain or supplies on-chain data off-chain.