About Oracles in Blockchains and How They Function in Exonum

alt

Development of blockchain solutions has introduced the issue of their access to external data, besides, trust to the delivered data is another topical question - how can we be sure that the received data are correct and have not been modified by an intruder? Both matters can be handled by the same solution – a special utility called oracle.

In this article we will discuss how oracles are presented in various blockchains and how we have implemented them when developing our open-source platform for building private blockchains - Exonum.

Example of Oracle Implementation

Let’s consider a situation when a decision should be made based on some voting. For this purpose, we use a blockchain which includes smart contacts to describe the business logic of the voting procedure. It is important to keep in mind that the procedure has its defined start and end time. When the voting process finishes, its results are summarized.

We need to know the exact time when transactions were committed to the blockchain to correctly analyze and count the votes. However, the time specified within Bitcoin or Ethereum blocks is not quite accurate, as different nodes have different time; whereas the precise time when a block was committed is not of high importance for public blockchains. What really matters for the hash rate calculation is the periodicity of committing new blocks. Therefore, knowing a relatively correct time is sufficient.

Exonum blocks don’t include the time when the block is committed for the same reason of time variation on different nodes. To define the precise time, we implemented a separate algorithm for calculating a single time value.

For the correct service implementation for our voting case, we need a reliable source of time. Generally, such cases require an external source of information. That’s where oracles come into play.

Why Oracles?

Oracles are utilities, which address external sources of data upon program request.

For smart contracts in general, and for Exonum services in particular, the external world is not available. On the contrary, oracles can retrieve the required data from it and transfer the information about important events. Data collected by an oracle upon service request, is committed to the blockchain with the help of transactions.

Examples of such data are the current time or the US dollar exchange rate. Apart from that, an oracle can establish a connection to another blockchain. For example, Exonum includes a Bitcoin oracle for anchoring an Exonum private blockchain to the public Bitcoin blockchain. We will further discuss this oracle in more detail.

Requirements for Oracles

Before implementing an oracle, we need to define the list of its necessary features. Since the collected data will be sent to a blockchain, it is natural that the requirements for oracles should coincide or stem from the characteristics of the blockchain.

When developing oracles for Exonum, we defined two key requirements, which every oracle should meet. Firstly, an oracle should be a concurrent data source, i.e. the data submitted to the blockchain should be a result of consensus on the information obtained from several external sources. Secondly, we need to trust the oracle and the data it provides. Therefore, an oracle should be decentralized, to avoid a situation when it unexpectedly crashes or is hacked.

Types of Oracles

Let’s consider the main, in our opinion, types of oracles and analyze whether they correspond to the requirements described above.

  • Simple Oracle

A simple oracle is a single node, which receives data from an external source and publishes it to the blockchain. The disadvantage of such a system is that we can trust neither the node, as we do not know its code, nor the data, as it is collected by a single node from a single source and can be incorrect.

  • Oraclize

The developers of the Oraclize service in their implementation of a blockchain have advanced deeper in resolving the issue of trust described previously. This data transfer tool provides users with cryptographic evidence that the information, provided by a selected source, has not been forged by the node while submitting it to the blockchain.

The Oraclize service solves the problem of trusting the oracle, however, the received data still cannot be trusted, as the source can send intentionally incorrect data, with no means of checking its authenticity.

  • Oracle with Known Source Code

The system resembles a simple oracle, however, due to the node’s code being open, the accuracy of its operation can be checked anytime. This approach, similarly to Oraclize, provides trust to the data source, but does not offer a possibility of checking the correctness of data itself.

  • Oracle with Multiple Sources

According to the requirement of the trustworthy data, it should be received from as many sources as possible. In case of multiple sources configuration, we get an opportunity to analyze the collected information and come to a final approved value. However, as there is still only one oracle, even if its code is available for check, it, nonetheless, constitutes an easy target for an external attack.

  • Oracle Network

In comparison to previous options, an oracle network wins in matters of stability in case of an attack or crash of its separate nodes.

Furthermore, if each oracle within the network has a separate data source, we can solve the issues of trusting both the data source and the collected data itself.

Oracles Implementation within Different Blockchain Systems

Now that we have a clear understanding of the desired oracle architecture, let’s review the most popular use cases:

  • Bitcoin

Scenarios for smart contact behavior have been intentionally limited in the Bitcoin blockchain. On the one hand, this decision led to a greater stability of Bitcoin as compared to other blockchains; on the other hand, the limitation doesn’t allow a full support of oracles in this blockchain. Only the simplest scenarios are possible, which generally are not similar to traditional oracles.

  • Ethereum

Since there is a large diversity of smart contracts in the Ethereum network, as compared to Bitcoin, there are more possibilities for implementing different oracles. As an example, we can mention BTC Relay, which connects the Ethereum and Bitcoin blockchains. The goal of this oracle is to allow Ethereum smart contracts to check whether a particular transaction exists within Bitcoin. Ethereum users (transmitters) send headers of new Bitcoin blocks generated by miners to BTC Relay. In their turn, smart contracts, knowing the Bitcoin blocks headers, can check the existence of the required transaction within a Bitcoin block.

Anyone can join the Ethereum network and become a transmitter. In addition, the chain of Bitcoin blocks and the hash of the block containing a particular transaction are difficult to forge. Therefore, the data sent to BTC Relay is considered reliable a priori.

  • Augur

Augur is widely spread in Ethereum. It is a decentralized platform, in a form of a market of predictions, where users, who are called oracles, can make predictions on different events. If predictions come true, users receive rewards in the form of tokens, which are called REP (short from “reputation”), and their reputation within the system grows.

In general, the algorithm of its operation is as follows. One node or a network of nodes address an external data source, for example, to analyze the current price of shares in a stock market and make predictions on how their price will change in the future. The final result, which will be committed to the Ehtereum blockchain, is chosen by signing a multisig-transaction. A transaction will be signed only when enough oracles agree that the condition has been fulfilled.

  • Fabric

The approach to oracles offered by Hyperldger Fabric is quite simple. In this blockchain, addressing data is done by a single selected node, while other nodes agree that exactly this external data was received by the oracle.

Examples of Exonum Oracles

Let’s take a look at two oracles implemented in Exonum - the time oracle and the Bitcoin oracle for the anchoring service, which was briefly mentioned above.

  • Time Oracle in Exonum

While forming the requirements for this oracle, apart from the general characteristics described earlier, we also considered the following criteria:

1) Since Exonum is an engine for private blockchains, the business logic of time definition was naturally delegated to the network validator nodes. Furthermore, the process of time definition should be resistant to Byzantine behavior of network nodes, that is, the time should remain precise even if up to a third of validators are hacked.

2) Time should be strictly determined: the final value should be written to the blockchain and should be identical for all nodes within the network. Otherwise, if the calculations of nodes differ, they will not be able to define the hash of a new block and further operation of the consensus algorithm will become impossible.

3) Time should be relatively precise. In reality, a deviation of a few seconds is considered acceptable.

4) Time should grow monotonously, for practical reasons. This will simplify its usage in the related business logic.

Within the algorithm, nodes provide the time value in the UTC format to account for the possibility that nodes can be located in different time zones. To define the precise time, nodes use external resources such as tlsdate, roughtime and others.

By default, each node sends a transaction with its current time value after committing a new block. The time service collects new values from all validators and adds them to the corresponding index (a “table” in Exonum terminology), which is updated after every time transaction received from any of the nodes. To calculate the final time value, nodes select one third of all responses, which is considered to be the most up-to-date. A special algorithm has been implemented to select and calculate the network time.

Supposing the number of validator nodes within the network is “N”, then the maximum number of Byzantine nodes for the system to remain operational is “f = N / 3”.

After each completed time transaction, the system takes the latest values received from the current validators and sorts them from the newest to the oldest ones. The number of collected values should be “2f + 1” for the algorithm to operate.

Let’s assume that “T” is the number of collected time values, which are sorted in the order described above. Every value in the range between “[f + 1]” and “[2f + 1]” either belongs to an honest validator or is located between the values of two honest validators, and, thus, can be considered reliable.

alt

For convenience, our algorithm writes to the blockchain the time, which corresponds to the “[f + 1]” interval, as it most precisely corresponds the requirement of monotony.

Since the transactions are sent by the validators after committing each new block, the index with the time values from the validators is updated with the frequency of block committing, which is approximately every second. Such deviation from the real time is considered acceptable with regards to the initial requirement for accuracy.

Bitcoin Oracle in the Anchoring Service

Anchoring is a periodic commitment of the hash of the Exonum private blockchain state to the Bitcoin blockchain. Transactions committing said Exonum state hash are called anchoring transactions.

Once an Exonum state hash appears in the public blockchain, it is impossible to forge or rewrite the private blockchain, as the Exonum hash at the same blockchain height, written in the Bitcoin blockchain, will not match the one, generated by an attacker. Such attacks become immediately noticeable. Therefore, the anchoring service raises the level of private blockchain security to that of a public one.

The service builds another chain of anchoring Bitcoin transactions atop of the Exonum blockchain. To define which anchoring transaction is the latest one and create the next one, we need the Bitcoin oracle.

To understand the algorithm of forming anchoring transactions and the structure of their chain, we need to recollect how transactions operate within the Bitcoin network. Every Bitcoin transaction has its inputs and outputs. New transactions inputs are the numbers of outputs of previous transactions, whereas outputs are the addresses where funds are sent. In addition, senders must prove that they possess the inputs by signing the transaction.

Apart from common Bitcoin transactions there are multisig transactions, which require several signatures for execution thereof (for example, three out of four).

Additionally, you can add a special output to a transaction, which leads nowhere; instead of the address, it includes some meta information not exceeding 80 bytes. Therefore, anchoring is the process of sending bitcoins to a BTC address with simultaneous storage of height and hash of an Exonum block in the Bitcoin network.

To define which transaction should be taken as the input, we need to find the transaction, whose outputs have not been used before. Such transactions are called unspent transactions.

Similarly to the time oracle, every validator in the Exonum network connects to a personal external source - a Bitcoin node, and requests a list of unspent transactions to the anchoring address. Next, validators find the latest anchoring transaction from the list and generate a new transaction with the information about it. For convenience, we call the latest unspent anchoring transaction – a LECT (Latest Expected Correct Transaction).

When the anchoring time comes, validators need to reach a consensus regarding the actual LECT. As soon as "2f + 1" nodes come to an agreement, we have an opportunity to form a new anchoring transaction and broadcast it to Bitcoin nodes. After a while, this transaction will also appear in the list of LECTs.

Even if a certain number of transactions is lost because of a fork in the Bitcoin blockchain, it will be possible to restore the chain by reverting to older anchoring transactions.


The work of Exonum developers on blockchain oracles continues. At the moment we are preparing an oracle similar in its nature to the previously mentioned BTC Relay for Ethereum. With the help of this oracle, Exonum users will be able to check the presence of certain transactions in the Bitcoin network.

In addition, there are plans to integrate Exonum with Ethereum. Blockchain enthusiasts will be able to use our findings in this field to construct their own oracles.

You can follow our progress via our official GitHub channel. There you can also leave your comments and contribute to the Exonum platform development.