Blockchain Oracles: why do you need them

Understand why smart contracts cannot manage real-world information and how Oracles try to solve this problem.

Why Oracles

The term “Oracle” comes from Greek mythology, where it referred to a person who could see events of the future by communicating with the gods.

An oracle in the context of blockchains is a system that can provide Ethereum smart contracts with external data sources.

But why smart contracts are unable to manage off-chain/real-world information?

The Ethereum Virtual Machine is a critical component of the Ethereum platform, with the ability to execute programs and update the state of Ethereum on any node in the decentralized network while adhering to consensus rules.

To maintain consensus, EVM execution must be completely deterministic and based solely on the Ethereum state and signed transactions. This is because each node on the network has to be able to produce the same result when a transaction is executed. If execution at different nodes gives different outputs, consensus will never be reached.

Non-determinism leads to failure in consensus

This has two significant implications:

• there can be no intrinsic source of randomness,
• external data can only be introduced as the data payload of a transaction.

Extrinsic information, such as randomness sources, price information, weather forecasts, and so on, can only be included as data in transactions sent to the network. However, such information cannot be trusted because it comes from untrustworthy sources. As a result, we have simply postponed the problem. An Oracle tries to solve this problem.

Oracles design patterns

The first thing to repeat and repeat continuously is that Oracle is not a product or a specific smart contract implementation, but rather:

Oracle is a design pattern!

The key functions of oracles are the capability of:

• Gather information from an off-chain source
• Send the data on-chain using a signed message
• Put the data in the storage of a smart contract to make it available

Once the data is in the storage of a smart contract, other smart contracts can just use message calls to access it.

The three major options for designing an Oracle are:

• immediate-read
• publish-subscribe
• request-response

Immediate-read Oracles

This kind of Oracle stores data in its contract storage only once and the data is updated very rarely. Those who wish to query this type of data typically do so on a “just-in-time” basis; the lookup is performed when the information is required and may never be repeated.

Examples of these Oracles include those that store information issued by organizations, such as academic certificates, institutional documents, self-sovereign IDs, etc.

For efficiency and most of all, privacy reasons, a recommended practice is not to store the raw data that the oracle is serving in the smart contract’s storage.

An effective way to design such a service would be to hash the data and only store the hash in the smart contract’s storage.

Publish-subscribe Oracles

When data is expected to change regularly and frequently, then a publish-subscribe Oracle could be the solution. It follows a similar pattern to RSS feeds in that the oracle is updated with fresh information and a “flag” indicates that new data is available to those who consider themselves “subscribed.”

To determine whether the most recent information has changed, interested parties must either poll or listen for updates of the oracle contracts.

While polling is very inefficient in the world of web servers, in the context of a blockchain ecosystem, polling for data changes is a simple local call to a synced client. Then, Ethereum event logs make it particularly easy for applications to look out for Oracle updates.

Examples of these Oracles include those that manage information such as price feeds, weather information, economic or social statistics, traffic data, etc.

Request-response Oracles

This kind of oracle fits well when the data space is too large to be kept in a smart contract, and users are only intended to consume a small portion of the total dataset at a time.

It is usually implemented as a two components system with:

• on-chain smart contracts
• off-chain infrastructure

The data request is typically an asynchronous process involving several steps.

First of all, an EOA interacts with a decentralized application (1), which is a call to a function defined in the Oracle smart contract with some associated arguments such as a callback function and scheduling parameters. This function realizes a blockchain transaction (2). Once this transaction has been validated, the off-chain infrastructure comes into play. It is used to monitor the Oracle request (3) (that can be observed as an EVM event emitted by the Oracle contract, or as a state change). The arguments are used to perform the actual query of the off-chain data source (4). Finally, the resulting data is delivered in a transaction to the decentralized application that made the request (5).

The oracle may also require payment for processing the request, gas payment for the callback, and permissions to access the requested data.

Oracle example

Here is a basic example of a request-response Oracle implementation by Provable™. The original code can be found here on GitHub.

To integrate with Provable, the contract DieselPrice must be a child
of usingProvable. The usingProvable contract is defined in the provableAPI.sol file.

The EOA requests the data by calling the update() contract function.

The data is actually requested by the provable_query function. This is an overloaded function that expects at least two arguments:

• the supported data source to use (URL in this case, but also WolframAlpha, IPFS, or others are available)
• the argument for the given data source, which may include the use of
  JSON or XML parsing helpers

Once the data has been retrieved from the desired external source, the __callback() function is called by an account controlled by Provable that is allowed to call the callback; it passes in the response value and a unique _myId argument, which, for example, can be used to handle and track multiple pending callbacks from Provable.

Conclusions

Oracles play an important role in smart contract execution by bringing external facts into the equation. On the other hand, they introduce a potentially huge risk. With this approach, one has to trust not only the Oracle company offering this service but also the service provider (fueleconomy.gov of the example). The Oracle service company can be either malicious or the data can be corrupted. In this way, the contract they feed is exposed to potentially false input, compromising its execution.

New to trading? Try crypto trading bots or copy trading