The Problem of Blockchain Oracles – Interview with Alexander Egberts

by Mike Fecke

The Problem of Blockchain Oracles: How the input of external data might foil the benefits of Blockchain technologies 

After furious price fluctuations and a big media hype of crypto currencies, Blockchain technology seems to be more popular than ever. Besides payment methods, we can also notice serious discussions about implementing Distributed Ledger Technologies into other important fields which may touch our daily life like data security or even e-Government.

The main advantages of the technology seem to be reasonable and of outstanding importance in a world that gets more and more complex by trends of increasing government regulation, bureaucracy and a loss of trust in various sectors: A Blockchain helps to improve the transparency and security of different processes and may improve their efficiency.

However, in order to implement these benefits, we must not subject to unreflective euphoria, but maintain a critical perspective in order to point out and resolve potential issues that might hinder the comprehensive application of new technologies.

After his first state examination in law, Alexander graduated with a master’s degree in business sciences while working as a research assistant in the areas of IT law and data privacy law at a large law firm in Frankfurt am Main. He wrote his master thesis about the topic of Blockchain Oracles and how they might influence a widespread adoption of Blockchain technologies in the near future. The thesis was supervised by Prof. Rasa Karapandza, holder of the Chair of Finance and leading Blockchain expert at EBS University.[1]

Currently, Alexander Egberts is a legal research and teaching assistant at EBS University in Wiesbaden, where he examines the relation between Decentralized Ledger Technologies, trust and contractual behavior. He promotes the creation of a legal framework for Blockchain technologies in Germany by supporting associations with this objective.

Mike Fecke: Alexander, you are a Blockchain enthusiast and engaged in bringing the Blockchain development forward. What excites you about this topic?

Alexander Egberts: I first got into deeper contact with Decentralized Ledger Technologies (“DLTs”) after a friend of mine introduced me to Ethereum in 2016. While I have been familiar with the concept of Bitcoin and cryptocurrencies before, it was the possibility of creating decentralized governance systems and smart contracts which really caught my attention. It fascinates me to this day that a seemingly small idea – like creating a decentralized way of transferring value – is now potentially able to advance (some might even say “disrupt”) many every-day procedures throughout many different sectors. The fast-paced development of this topic and the momentum with which smart minds from every sector cooperate in order to promote this technology amaze me.

Mike Fecke: You wrote a thesis on Blockchain Oracles. Could you explain in a non-technical way, what exactly an “Oracle” is and why we do need it?

Alexander Egberts: You could think of an Oracle as a “gateway” between the Blockchain and the real world. Just like in ancient Greek mythology, an Oracle connects two realms: While being a smart contract itself, the Oracle would be contacted by other smart contracts in order to retrieve information from the “real world”, meaning any information that is not yet stored on the Blockchain, in order to put it onto the Blockchain for further use. This is necessary, because the computers in the network which execute the smart contract code (called “nodes”) cannot retrieve external information by themselves. If they did, it would simply need an inconsistent response (such as a randomized answer to the data-inquiry or a temporary time-out of the inquired source) to shut down the entire network: Diverging inquiry-results would prevent the nodes from finding a consensus during the block validation process. Without such a consensus, no new blocks could be created, so that the whole decentralized network would be in jeopardy.

To resolve this issue, we need Oracles: In a previous step, they extract data from the “real world”, pre-collect the results and then save it on the Blockchain. Now, if a smart contract needs such data to execute on, all nodes can agree on the same information, as it is already stored on the Blockchain. Hence, they can find an identical state of information and create a new block.

For a widespread adoption of Blockchain technologies, this is of high importance, because many of the anticipated use cases for smart contracts and decentralized apps depend on data that is not existent on the Blockchain a priori. To name a few: the BTC/USD exchange rate to provide a hedging mechanism; the weather report for crop insurance; the amount of gigawatt produced by a solar panel for an automated sale of electricity; the outcome of an election for a prediction market. All these smart contracts rely on Oracles to work.

Mike Fecke: So far this sounds alright to me. What exactly is supposed to be the issue with Oracles here?

Alexander Egberts: Oracles are absolutely necessary and form an indispensable part of the Blockchain cosmos. But when we look at why the use of Blockchain technology is advantageous to us in the first place, we can see a certain contradiction when it comes to the use of Oracles: Roughly illustrated, the use of Blockchains mainly results in two major advantages: the security architecture and the missing necessity for trust it involves.

The firm security architecture is not (only) obtained by the cryptographic encryption that is used, but predominantly because of the distribution of the database: With storing the information on a multitude of nodes instead of a (few) centralized server(s), the single point of failure is eliminated. This way, manipulating the stored information – by hacking or social engineering – becomes insurmountably difficult. Attacking a single database already is difficult, given the contemporary means of security – now imagine attacking several thousand, running on different operating systems, at once.

Arising from the security advantages comes the second virtue Blockchains can bring: With trusting in the integrity and functionality of the underlying code, users can be confident of the validity of their transactions without the need of placing trust in an intermediary or the transaction’s counterparty. This way, the “middlemen of trust” can be cut out. This could firstly reduce transaction cost for market participants as costly precautions become unnecessary and secondly enable financial interactions in countries where trustworthy middlemen do not exist. This can lead to an economy that creates greater efficiency and fairness for each participating individual. In a paper from 2016, UPenn professor Kevin D. Werbach described this phenomenon as “Trustless Trust”[2].

However, when relying on Oracle Service Providers to deliver the correct information, both the single point of failure and the necessity to trust in the correct behavior are reintroduced to the Blockchain network: In order to manipulate the outcome of a certain smart contract (let’s say a betting contract) the Oracle could be attacked by a third party or its provider could deliberately provide false data to make a profit from the incorrect execution of the contract that results from the false data. The security advantage is practically nil.

This “ability to misbehave” however reintroduces the necessity for trust when dealing on a decentralized platform. To encounter the potential risk, an economically rational acting individual would be obliged to perform a due-diligence of the Oracle Service Provider or even care for legal precautions given the possibility of misconduct before using any dApp. This, however, leads yet again to an increase in transaction costs. The main reasons for dealing with a decentralized platform in the first place are undermined. It gets even worse if we consider that legal enforcement is currently still very difficult to perform on a Blockchain.

Mike Fecke: Why do you think the problem of Blockchain Oracles is important enough to write a master thesis about it?

Alexander Egberts: This “Oracle Problem” creates sort of a paradox: While every use case depending on Oracles aims to extend the users autonomy from trust-intermediaries, it also intensifies the need for the user to trust in the correct behavior of the Oracle. However, most of the crypto- and blockchain-enthusiasts I meet are hardly aware of this issue. When recognized in academic work, the problem is mainly discussed from a computer-scientific perspective – the IC3 of Cornell University did some seminal work on this, for example. However, I wanted to initially examine this problem from an economic and legal perspective in order to call wider attention to it and make the issue accessible for different academic fields. While the aim to create a Blockchain-based economy understandably creates euphoria, we should still maintain a critical view of the potential obstacles that are still in our way to achieve this.

Mike Fecke: Sounds good to me! And which concepts do exist to solve this problem?

Alexander Egberts: To answer this, we have to differ between Human Oracles and Automated Oracles. Human Oracles “create” new information when several users report on a specific event. Using game theoretical approaches, a truthful response can be ensured with high probability, when some sort of incentive is provided for carrying out a correct report.[3] This approach is mainly used in prediction markets at the moment. While misbehavior can occur when the potential payoff is higher than the incentive offered for entering a correct answer, it will be difficult to coordinate the multitude of reports to report falsely. As a result, Human Oracles do in fact appear to be quite safe.

However, as utilizing the human cognition is time-consuming and expensive, many applications will depend on using preexisting structured information instead. Automated Oracles can retrieve this structured information as an API from predefined existing data sources, such as wikidata.org, Bloomberg, etc. Yet, the Oracle Service Provider could simply choose to act untruthfully to deceit a certain smart contract and receive a pay-off. Additionally, a predefined data source could pretty much pull off the same heist once it becomes aware of its role.

The majority of Oracle Service Providers do address this problem, but most of them fail to resolve it. The approach of the currently most commonly used Oracle Service Provider is trying to establish their trustworthiness by creating a visible track-record –comparable to how rating agencies aim to establish their credibility. This, however, misses the whole point: If you are trying to convince me to why I should trust you, I still do need to trust you. Trustless Trust is not maintained at this point. Now, you could argue that transaction costs would still be decreased since it would be “easy” to trust such an Oracle. But firstly, a positive track record does not ensure that the involved party behaves correctly once misconduct might become economically reasonable and secondly, there are some smart contract use cases that just can’t allow even the slightest possibility of a faulty execution (e.g. use in finance/hedging).

Mike Fecke: Which solution is the most promising one?

Alexander Egberts: There is an Oracle Service Provider called ChainLink which aims to create a decentralized Oracle by making several Oracles (which work like “freelancers”) retrieve information from a multitude of data sources and then aggregates the results. If an Oracle’s results deviate too much from the mean value, they will be excluded from the aggregation process and such Oracle will have less influence on future aggregation processes. While this does not eliminate all the issues connected with Blockchain Oracles – for example: it would still be possible for the central Oracle to influence the data, data sources / Oracles could collude, and universal misinformation could influence the aggregation outcome – it can be considered an important step into the right direction.

Additionally, there is an approach to creating a protected software execution environment on the computer’s CPU. This way, the Oracle provider would be prohibited from influencing the data communication or aggregation process. While the concept of these proposals is potentially effective, there recently have been some reports about safety-related concerns with these programs.

Mike Fecke: Alexander, thank you for the interview!


The original thesis is currently being edited in order to be submitted to a journal

[1]https://www.ebs.edu/en/news/a-personal-invitation-to-the-u-s-congress-prof-ra%C5%A1a-karapand%C5%BEa-got-one.

[2] This term was very well received within the crypto community. Although Werbach retracted this thought from the original paper, this approach is further elaborated on in his forthcoming book “The Blockchain and the New Architecture of Trust”. While the term Trustless Trust was used before by Reid Hoffman in a Wired UK article from 2015, it seems fair to say that Werbach`s paper contributed more to the spreading of this terminology, due to its wide circulation.

[3] This is done by using something Nobel laureate Thomas Schelling describes as a focal point: Even if two people have had no prior interaction, they will usually be able to anticipate one another’s actions to a certain degree. Resulting from this, inquired reporters will usually respond in a way which they think most people would. This clears the responses – at least to a certain degree – from the reporters’ subjectivity and therefore leads to a rather neutral response.