Decentralised 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 multiple third-party services named a decentralised oracle. Oracle instances query and verify external data sources and then relays that data into the blockchain in the form of transactions forming an authoritative record(s) 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.

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. While a centralised oracle could provide the data, it introduces a trusted third party into the system. This centralises trust and might become a single point of failure. How can smart contract functions access the state of the external world with higher levels of trust and availability?

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 sources and transaction senders.
Reliability and Availability – A centralised oracle becomes a single point of failure. In the case that the status injected into the blockchain is a faulty status, the whole system might behave incorrectly. In the case that the oracle is unable to inject any status to the system, depending on the criticality of the status to execute smart contract logic, the whole system might get stuck and unavailable.
Validity – The data source(s) could be a static web page, physical sensor, component of a system, or even input from a human. Certain applications may also demand acquiring data from multiple independent sources to enhance validity. Technically, the data from different data sources can be integrated either by the oracle or outside the oracle.
Cost – The cost of data retrieval from the external world is proportional to the number and size/complexity of transactions.

Solution

To improve the trustworthiness of an oracle, a set of decentralised oracles could be used. Each oracle uses a separate server (i.e., off-chain component) and queries the data from an independent data source. Similar to the centralised oracle design, a transaction could then be submitted to the smart contract that wishes to use the data or on-chain component of the oracle (i.e., oracle smart contract). The smart contract can then determine the data submitted by a majority of oracles as the valid representation of real-world data/state.

Decentralised Oracle Pattern

How the validity of data is determined might be specific to an application or oracle design. For example, on-chain or off-chain component of each oracle (or a majority of oracles) can submit its data to the application by calling the relevant smart contract function. The smart contract can then choose the valid data as per its business logic, e.g., a simple majority. Alternatively, we can have an on-chain oracle smart contract that aggregates data from each off-chain component (or a majority of them), determines the valid data based on the majority, and then reports the valid data to the application. We could also push the data aggregation and validation to an off-chain component that uses k-out-of-m threshold signature scheme to reach a consensus on the data to be injected into the blockchain. For example, a 3-out-of-5 signature scheme requires at least 3 or more decentralised oracles out of the 5 oracles to sign on the same transaction containing the data to be injected into the blockchain.

Each of these approaches has its own merit. For example, by submitting data to the application, it receives all data and can verify the identity of oracles that submitted the data, and perhaps even the source of data. Whereas in the second approach, the application receives only the validated data from the on-chain oracle component. Both approaches however result in multiple transactions being submitted to the blockchain. Alternatively, the k-out-of-m threshold signature scheme authenticates multiple oracles using a single transaction reducing the transaction fee. However, k-out-of-m threshold signatures may not be natively supported by a blockchain platform; hence, could increase the cost of executing that transaction to validate the k-out-of-m threshold signature. Despite having multiple oracles, it is important to note that some information, such as the owner of a property, may ultimately come from a single authorised source.

Benefits

Reliability and Availability – By having multiple oracles to retrieve data from the external world, the risk of validating transactions based on faulty/failed external data is reduced. Acquiring data by multiple oracles also improves the reliability and the confidence of the final accepted value. The oracles are allowed to fetch the requested data from multiple external data sources, improving the likelihood of getting accurate and timely external data, even if some of the sources may not be always available or responsive.
Connectivity – The closed execution environment of blockchain is connected with the external world through the oracles. The applications based on the blockchain can access external states through the oracles and use these external states in their execution.
Trust – A decentralised oracle increases trust as it relies on trust on a majority of third parties.

Drawbacks

Trust – A decentralised oracle still introduces trusted third parties into the system. All the oracles that verify the external state needs to be trusted by all the participants involved in relevant transactions. Thus, trust needs to be extended from a single entity to multiple ones.
Cost – The cost of using a piece of data from the external world increases with the number of oracles being used.
Time – It might take a longer time for multiple oracles to get the required information and reach a consensus over the final result. If all oracles need to agree, the time is bound by the slowest oracle. If a subset of the oracles is sufficient, then the slowest oracles can be ignored, thus potentially speeding up the process.
Uncertainty – Compared with a centralised oracle, a decentralised oracle introduces more uncertainties. When human is involved, the value what majority vote becomes the result, which might be different from the truth in the physical world.

Related patterns

This pattern is based on the multiple instances of the oracle pattern
Reverse oracle pattern could be used to provide on-chain data to off-chain components where data flow is reversed.
Voting pattern can be used by decentralised oracles to vote on data validity.

Known uses

Orisi on Bitcoin maintains a set of independent oracles. Orisi allows the participants involved in a transaction to select a set of oracles and define the number of oracles to agree on the data before initiating a conditional transaction.
Gnosis is a decentralised prediction market that allows users to choose any oracle they trust, such as another user or a web service, e.g., for weather forecasts. A human oracle is also called an arbitrator, who is trusted by the interacting participants to resolve disputes or check external states.
Augur is another prediction market that leverages the capability of human oracles to do predictions and resolve disputes.
Merchant Token uses a decentralised oracle to confirm a product/service delivery or resolve disputes before releasing funds locked in the escrow to the seller.