Design Questions of Blockchain Oracles

Published by Mario Oettler on

Blockchain oracles can be designed in many different ways. Here, you will find a list of possible design choices that a participant or oracle operator should consider.

  • What data source?

In some cases, we have many data sources. Here we need to decide which data source an oracle should tap into and which it should ignore. This is an important question because different data sources can provide different data. Besides the different data, data sources can disappear while others appear.

  • When to access the data?

If we have decided upon the data source, the next question is when should the oracle request it?

  1. Immediate Read: Data is stored in the oracle contract; users can read these data at any time. Data might be updated occasionally.
  2. Publish-Subscribe: An oracle fetches data regularly. The user actively polls the oracle or the oracle notifies the user if new data is available.
  3. Request-Response: If a user needs some data, it requests the oracle. The oracle then tries to find a data source, retrieves the data from there and forwards it to the user.

Intentional and unintentional manipulation is possible by choosing the request time.

  • How to deal with unresponsive data sources?

Like every online service, data sources can suffer from downtime, data loss, or a slow internet connection. This means an oracle cannot rely on the reporters to send an answer. Hence, it must implement a method to deal with downtimes.

  • How exact should data be?

Imagine someone asks the value for the constant pi. How many decimal places should the oracle provide? Two, five, thousand, or one million?

Data accuracy can be very crucial when it comes to decisions. In edge cases, even small rounding errors can sum up and influence the decision of a smart contract.

Although the accuracy could be stated in the transaction, the data source would need to be able to provide such accuracy.

  • How to verify the correctness of data?

Trusting the oracle is a valid strategy. But it poses the risk of fraud. The opportunity of verifying provided data is crucial.

  • How to remunerate the data provider?

Collecting and processing data is costly. Oracles and reporters need to be remunerated for their service. There are different ways to do this, either by pay-per-request or by a flat fee.

  • Grade of centralization

Centralized oracles consist of one node which collects and aggregates all data. With decentralized oracles, the data collection and aggregation are done on-chain in a smart contract or in another peer-to-peer network.