Oracle

Disclaimer: This is a summary of patterns we have observed during our research and should not be considered any form of technical or investment advice. Also, the given “known examples” do not imply they are the best implementations of the said pattern or any superior to any other implementation of the pattern not listed.

Summary

Introduce the state of external systems into the closed blockchain execution environment through a third-party service named an oracle. An oracle queries and verifies external data sources and then relays that data into the blockchain in the form of a transaction forming an authoritative record of data.

Context

From the software architecture perspective, blockchain can be viewed as a component or connector within a large software system. In the case where blockchain is used as a distributed database for more general purposes beyond digital assets, the applications built on a blockchain might need to interact with external systems. Thus, the validation of transactions on a blockchain might depend on the states of external systems. For example, a payment may be conditional on the physical properties of a product/service or completion of a real-world activity such as quality attributes of a product or shipment of a product. Typically such data are provided or certified by third parties.

Problem

The execution environment of a blockchain is self-contained. It can only access information present in the data and transactions on the blockchain. Smart contracts running on a blockchain are pure functions by design. The state of external systems is not directly accessible to smart contracts. Yet, function calls in smart contracts sometimes need to access the state of the external world. How to fetch external state/data into a smart contract to access the state of the external world?

Forces

Closed environment – Blockchain is a secure and self-contained environment, isolated from external systems. Smart contracts on blockchain cannot directly read the states of the external systems.
Connectivity – In addition to the data found on the blockchain, general-purpose applications might require information from external systems. For example, supply chain management relies on information such as geolocation or weather data pulled from third-party services.
Authenticity – On a public blockchain any party can provide external data into the blockchain. Hence, the authenticity of the submitted data depends on factors such as authenticity, reputation, and reliability of the data source and transaction sender.
Trust – Both the transacting parties need to agree on the state of a product and its attributes. When such data are provided by a third party, the provider needs to be trustable to transacting parties, including any regulators.
Availability – While transactions on a blockchain are immutable, the external state used to validate a transaction may change or even disappear after the transactions were originally appended to the blockchain.
Cost – The cost of data retrieval from the external world is proportional to the number and size/complexity of transactions.

Solution

As seen in the following figure, use an independent, third-party service to connect the closed execution environment of blockchain with the external world. The third-party service could query and verify the external data needed by a smart contract function and then submit that data to the smart contract using a transaction. Such a service is referred to as an oracle.

For example, when validation of a transaction depends on the external state, the oracle is requested to check the external state and inject the result to the blockchain in a signed transaction. Data provided by an oracle is considered to be trustworthy by the respective smart contract. The oracle’s authenticity is proved by its identity and digital signature of the transaction. However, it is worth noting that from the perspective of the blockchain, the data injected from an oracle is no different from data provided as an input to a smart contract function by other users. Hence, the role of an oracle could be played by a software component like a web service or a human.

Oracles could be implemented in several ways. For example, oracles could be implemented as off-chain components or as a combination of on and off-chain components. As illustrated in the following sequence diagram, an oracle could allow other smart contracts to either push or pull data from off-chain components. In the first case, the external system sends the desired data to the oracle smart contract using a transaction. This transaction should invoke a method that accepts data as an input parameter. For example, when a payment application needs to access the data, it can make a delegated call to the oracle smart contract to read the data. In the second case, the payment application indicates its need to access external data to the oracle using a delegated call. In response, the oracle emits a blockchain event indicating the desired data. The external system should poll for such events to determine what data are requested by the oracle. As the blockchain cannot directly interact with external systems, events provide a passive communication mechanism between a smart contract and external systems that poll for relevant events. Once the requested data are available, the external application submits the data to the blockchain using a transaction. Consequently, the oracle makes a delegated call to the smart contract to deliver the requested data.

When the smart contract calls the oracle, if it does not have the desired or latest data, a subscription could be made to the oracle by specifying the smart contract address and method to be called. Once the data are available, the oracle can call the smart contract using a delegated call. A new transaction could be issued every time the external state changes. Even if there is no change in data, some applications may require the external system to submit a transaction indicating no change in data. Further, instead of an oracle providing data reactively, it can try to be proactive by submitting data to the on-chain oracle contract in anticipation of a data request from another contract. Alternatively, in both implementations, we could replace event emitting and subscription with polling.

There are two types of oracles: centralised and decentralised oracles. A centralised oracle introduces a single trusted third party into the system, which might become a single point of failure. Alternatively, a decentralised oracle is designed based on multiple external servers and multiple independent data sources, overcoming the single point of failure. A decentralised oracle can use multisignature or voting to reach a consensus on the validity of data injected into the oracle. Similarly, at the hardware level, redundant IoT devices could be deployed to deal with adversary IoT devices that produce malicious data. Then the oracle smart contract can cross-check the consistency of data collected by different IoT devices.

Oracles can be used to access the physical attributes of a product to avoid fraud in trading. A physical item’s integrity can be verified by connecting the physical item with its digital representation (i.e., digital-physical parity). The physical attributes of an item (e.g., chemical composition, geo-location, and visual features) can be extracted via various techniques such as genomics analysis, isotope analysis, and machine learning. The captured attributes can be digitally recorded on the blockchain through oracles to ensure immutability and transparency.

Benefits

Connectivity – The closed execution environment of blockchain is connected with the external world through the oracle. The applications based on the blockchain can access external states through the oracle and use these external states in their execution.
Centralisation – Centralised oracle is more efficient in terms of monetary and time cost. It is easier to manage compared with a decentralised oracle.

Drawbacks

Trust – Using an oracle introduces a trusted third party into the system. The oracle selected to verify the external state needs to be trusted by all the participants involved in the application.
Data Integrity – The external states injected into the blockchain cannot be fully validated by on-chain components. They solely rely on the oracle to check the validity of the data from the external world. While transactions are immutable, the external state used to validate them may change after the transaction is appended into the blockchain.
Availability – A centralised oracle introduces a single trusted element, whose unavailability, failure, or compromise may prevent the blockchain from successfully completing the transaction verification process.
Cost – There is a cost in injecting data into the oracle smart contract and looking up data from the oracle. Further, the cost of injecting data from the external world increases with the number of oracles being used and the rate of data change.

Related patterns

The decentralised oracle pattern can be used to overcome the single point of failure.
The reverse oracle pattern could be used to provide on-chain data to off-chain components where data flow is reversed.
The policy contract and seller credential patterns can use an oracle to verify physical attributes about a seller or its products.
The multiple authorisation pattern can be used to sign the data submitted to a decentralised oracle.

Known uses

Oracle in Bitcoin is an instance of this pattern. Oracle is a server outside the Bitcoin blockchain network, which can evaluate user-defined expressions based on the external state.
Provable is an oracle service provider, which utilises trusted hardware to directly fetch information from an external trusted execution environment (TEE). Provable introduces three different proofs for fetching data from external data sources, namely, TLS-Notary, Ledger proof, and Android proof.
R3 Corda has a centralised oracle mechanism embedded in its platform. The oracle mechanism uses Intel Software Guard Extensions (SGX) for hardware attestation to prevent unauthorised access outside of the SGX environment.
Orisi is an oracle framework for Bitcoin smart contracts that enables the transaction participants to select a set of oracles and apply multisignature to confirm the status.