Basically, a blockchain is a tool for creating a global consensus about an (orderly) sequence of transactions. Common to all blockchains is that this consensus is created by as many participants as possible in a peer-to-peer network and can be independently verified by all participants. To this end, there are Miners which receive the transactions and combine them into blocks in competition with each other. In doing so, they also solve a cryptographic task, the difficulty of which lies in the fact that to create a block on average a certain time set by the network needs to pass – for example, with Ethereum this is about 15 seconds. These blocks then form a chain (the blockchain) the cryptographic relationship of which can only be falsified with a great deal of computational effort. In general, this is an audit-compliant transaction list that cannot be changed by normal attackers.

Smart contracts are an extension of this basic idea. Used extensively for the first time in the Ethereum system are small programs – so to speak – in each transaction. They are executed in parallel by all participating miners, while the result ends up in the blockchain forever. Such contracts with special functions can also access and even manage the monetary value of the transaction. So you could also refer to Smart Contracts as a type of programmable money. It is already conceivable that many areas of the financial world can be supplemented by smart contracts or their implementation can be further automated.

One challenge is to feed these smart contracts with data from the real world. Let’s imagine a scenario: The creator of the contract wants to assign the current exchange rate of the euro to the dollar to a variable. In a normal program on his PC, he would call up the API of the European Central Bank to get that value online. In the case of a smart contract, however, he does not know which machine will ultimately successfully add this transaction to the blockchain (there are thousands of miners, all of which compete with each other to be the first to solve the cryptographic puzzle and integrate the transaction into the blockchain), nor does he know what view of the world this particular computer will have. Who can guarantee that this computer is not behind the “Great Firewall of China” and indeed may have access to the Ethereum network, but access to the ECB website is blocked?

For these reasons, there is no intention in Ethereum to get data through the external interfaces of the executing computers. All input data must always reach the miner directly via a transaction in order to be included in a calculation. This interface between real world data and a smart contract is called an oracle.

Such an oracle usually consists of a function in a larger smart contract, which is called up by a transaction and can write to a variable in the internal state of the contract. If the variable needs to be updated, the information provider generates an Ethereum transaction with a call-up to this function with the desired value as a parameter. This transaction is sent to the network and ends up with all the miners; the miners then incorporate them into the global history and execute them. This means that in the Ethereum State Machine, a function in the Smart Contract is called which in turn sets the variable to be manipulated to the new value.

After this oracle transaction has finally landed in a block, the next read access to the variable will show the new value. All transactions (and function calls) in Ethereum happen atomically. Despite the extremely distributed calculation of smart contracts, there is no invalid state when reading a variable which only contains half of the update.

Problem in the financial sector

Due to the coupling of monetary transactions and Turing-complete programs, smart contracts are predestined for financial and investment banking applications. Any data needed from other systems, web interfaces and user inputs must be packed into transactions and transferred over to the executing smart contract. It’s not cheap though: The Ethereum Network generates transaction costs at the level of the sender of a transaction, depending on the network utilization. A kind of auction procedure is used here. Each transaction consumes a certain amount of “gas” depending on the compiled machine code of the transaction.

The gas should cover the costs of the miner, who eventually has to execute the code. A loop needs more gas than a simple instruction. For this gas (which can be deterministically calculated from the source code), the sender of a transaction then sets a price per gas unit, while the miners then search for the most profitable transactions for the next block. Thus a sender of a transaction can fairly accurately determine how quickly the transaction will end up in a block: If you set a low price, the transaction will be included in a later block later when there are fewer transactions on the network. There is no guarantee that a transaction will not starve because it was waiting forever for inclusion in a block.

These costs can range from a few cents up to a few euros per transaction. So at the end of 2017, there was a popular game called Cryptokitties as a smart contract. Just by the popularity of this one game, transaction costs increased enormously in a short period of time.

This cost argument leads to the idea of saving costs through shared data. So not everyone has to package the data of an API as an oracle independently just because the exchange rate between the euro and the US dollar is needed, but rather a shared oracle provides this exchange rate regularly and anyone interested can then programmatically access it. The sample source code of a very simple oracle for the exchange rate between the euro and the US dollar can be found in Listing 1. The oracle is based on real software that is used productively by BlockState. The programming language for smart contracts is Solidity. Basically, the oracle stores three variables: the actual value that should be saved (the exchange rate), the Unix timestamp of the last update, and the address of the entity allowed to update that oracle. The example is deliberately kept very simple – in general, these contracts are of course much more complex, like traditional object-oriented programs.

contract EURUSDOracle {
  uint256 public exchangeValue;
  uint256 public lastUpdateTimestamp;
  address owner;

  event oracleUpdated(
    uint256 exchangeValue,
    uint256 timestamp
  );

  constructor() public {
    lastUpdateTimestamp = 0;
    owner = msg.sender;
  }

  function updateOracle(uint256 newExchangeValue, uint256 newTimestamp) public {
    require(msg.sender == owner);
    exchangeValue = newExchangeValue;
    lastUpdateTimestamp = newTimestamp;
    emit oracleUpdated(newExchangeValue, newTimestamp);
  }

  function getExchangeValue() public view returns (uint256, uint256) {
    return (exchangeValue, lastUpdateTimestamp);
  }
}

In addition to the three variables, there is a so-called event. It can be called up from a smart contract function and then generates an event that can be monitored by a piece of front-end code. Common front-ends are JavaScript applications that provide Ethereum integration. This event can then be used to initiate further actions outside of the smart contract.

The main purpose of the designer is to define the owner, which will be the only one allowed to make updates later on. The usual code used to change ownership has been omitted for reasons of clarity.

Finally, the last two functions are the actual oracle functions: The owner uses the first one to update the oracle with fresh data. The function call-up is made via a normal Ethereum transaction, which includes the Application Binary Interface (ABI) of the smart contract and the parameters of the function. A miner can do this in the Ethereum Virtual Machine and write the result back to the blockchain. Afterwards, the smart contract stores the new value in the variables.

The last function can be used by anyone and does not require any gas as it only processes the last value of the oracle. This allows a node that reads the current state of the blockchain to automatically read this value locally and also use it in its own smart contract.

Due to its simplicity, this template is easy to adapt and can be flexibly used for all kinds of applications. The option of integrating it into other smart contracts makes it an interesting solution to use as a kind of building block in a larger context.

Reliability of the input data

As already indicated, the update of values in an oracle usually has to come from a trustworthy instance. This is where the community approach comes in – here a representative is appointed to submit the data. Another benefit of these community-shared oracles is the reliability of data. In the case of the exchange rate between the euro and the dollar, there may be little room for interpretation, but what about the price of Bitcoin, for example? This is determined differently in different stock markets worldwide. It is customary then to calculate an average from these prices. A single smart contract user may not be willing or able to provide a reliable collection service for all the data needed first of all. Existing aggregator services in this sector stand out with their inconsistencies and lack of documentation. Such a jointly operated oracle therefore needs reliable, well-defined and documented data sources first of all.

If all this is available, the oracle can periodically retrieve this data, pack it in a transaction and send it. This also automatically generates a history that invariably writes the price into the blockchain and makes it immediately transparent for viewers later on, whether or not the oracle has provided correct data in the past. Building on such a trusted oracle, financial applications which depend on correct data can then be implemented in smart contracts. BlockState develops such applications. The underlying community project that serves the oracles with reliable data as outlined above is called DIA and is a non-commercial entity.

Solution

As already indicated, the best solution for the oracle issue from the perspective of the author is an infrastructure operated jointly by the community, which on the one hand aggregates the raw data, pre-processes it and puts it in the oracle, and on the other hand, provides control mechanisms for the community.

Economic incentive systems are particularly effective in cryptocurrencies because of the native currency nature of the system, and so it makes sense to ensure data quality through such an incentive system. The DIA project has implemented such an incentive system. Open source developers can enter source code for data acquisition and processing there. With the token present in the system (a type of currency that is meaningful only in certain smart contracts), it is possible to determine an operation that bets on the acceptance or rejection of a specific piece of new source code for a particular documented task. After a few days, the smart contract automatically decides whether or not to accept the new code based on the bets. Also, a dispute system for errors or corrections discovered later on is provided. Financial applications based on this, such as those by BlockState, have then a solid foundation to process reliable and up-to-date data, for example, in another smart contract or in an application that is no longer on the blockchain itself.

Together with open-source source code, this results in a very transparent system in which it can be verified at any time (even for data that is already several years old) where the data comes from, how it is processed, what level of confidence supports this data and how the data is used. In the face of many unclear financial transactions in traditional investment banking, this should also be a welcome development overall.