One of the most important innovations brought by blockchain are smart contracts – the ability to execute code that can manage resources is powerful and versatile in all sorts of situations. There is however a problem in binding that power to the real world – blockchains cannot know anything about “the real world” on their own – they can only know what happens within the blockchain itself, any outside information needs to be “inserted” in it (currently as a transaction).
We initially explored this concept in our introduction to smart contracts, and mentioned oracles as the solution to the issue. This article will expand on oracles, describing them in more detail.
What are oracles?
Oracles are how we get information from the world into the blockchain and out of it. They take data from a source (be it a weather service, news, banking systems, anything really), and submit it to a blockchain as data contained within a transaction.
A typical example is to have an oracle submit weather forecasts of a certain location to a blockchain, and if it says “cyclone” then some earmarked funds are sent for disaster relief by the smart contract.
Web services in 2018 and the blockchain
What happens with normal web services is that a program would hit some endpoint, for instance a weather API, asking for data such as “yesterday’s temperature in Naples at 12:00”. That API will send back the requested data, and the program will do something with it. That is how weather apps work on smartphones – they request weather data from some trusted source and display it to the user.
Blockchain, however, is an entirely different matter. It is a deterministic system, meaning that from the same set of inputs the same output will arise. That is essentially why a new validator can connect to the network without needing to trust a single source for all the transaction info – they can listen to the network instead and piece together history block by block to reach the same conclusion, thus “syncing” with the rest of the network; if those inputs are for some reason not available, there’s a problem, and unfortunately “not being available” is a fairly common property of web services.
The issue of availability isn’t a simple “you can retry a few seconds later” either: imagine a (currently impossible by design) scenario in which a smart contract gets the result of a coin toss from an external service, and sends 20 bitcoin to Alice if it’s heads, or Bob otherwise. Imagine that the result is “heads”, and the funds are sent to Alice. If at any point in the future that service were to become permanently unavailable because the company running it went under, all nodes after that point would not be able to contact it, and would therefore not know what the result of the original coin toss was. Since the answer they receive is not heads (because they receive no answer), the “else” branch of that if/else is activated and the 20 bitcoin go to Bob instead. We now have some nodes believing that Alice has 20 bitcoin, and others saying that Bob has 20 – that’s a real pickle because there is no consensus anymore, they two branches disagree on the set of inputs and therefore the ultimate state of the blockchain is different.
The solution, then, is to make that data part of the blockchain itself: every transaction can include some extra data outside of the normal “send amount X to address A”, and there is where the information about the coin toss is stored. Since it’s now part of a transaction, it will be broadcast as part of the syncing process. The information has been successfully been converted from “external” into “internal”, with the help of some entity that queried the coin toss API and added that data to a transaction. That entity is an oracle.
Types of Oracles
There are different types of oracles that answer different needs.
Software oracles (click to expand)
Software oracles are a type of oracle that retrieves data from some some public source and “posts” it to a blockchain, usually attaching cryptographic proof that the data came from the requested source and was not tampered with.
It was popularized a few years ago through the concept of AWS oracles, which are oracles hosted on Amazon’s AWS platform – in theory, by publishing a representation of the initial state of the oracle and all changes thereafter, the oracle can theoretically be trusted under normal circumstances because it’s possible to make sure that it has not been tampered with.
Sometimes readings are required from the real world, and they have to be submitted in real time. This is where hardware oracles come in – working exactly like other sensor, with the addition that they are blockchain-enabled (in the sense that they can submit data directly to a blockchain).
They are somewhat problematic in the sense that the information they provide cannot usually be verified, unless there is another sensor in the vicinity for the same data-point, and they can therefore be tampered with.
The logical step forward is sensors to detect tampering, as they exist in all kinds of devices already: in this case, the detection of somebody tampering with the oracles would wipe the private key of the oracle, preventing it to sign any more transactions; I am however not aware of any project that uses anti-tamper hardware oracles “in the field” at the time of writing.
A third type of oracle is based on the concept of wisdom of the crowd, in the form of a prediction market. In such a market, a question is posted and participants bet on the outcome they believe will have the most votes. Through a game theory lens, as they have no knowledge of the outcome participants tend to focus around the “obvious” answer. As an example, for the question “Which of the following options will the majority choose?”:
I can expect most answers will focus on the third, “apple”, as the odd one out. This is known as a Schelling point, (defined in Wikipedia as “a solution that people will tend to use in the absence of communication, because it seems natural, special, or relevant to them”), and is the principle on which prediction markets are founded, as “the truth” is a natural Schelling point. That is not the whole story, of course: as with every economic incentive to good behaviour there are a number of factors to be taken into account, most notably malicious actors trying to game the system. Reputation is an addition to prediction markets specifically designed to try and ameliorate the issue by creating semi-trusted entities with a proven track record.
A big issue for current oracles is that they work as trusted entities: you’re either running your own oracle, relying on companies providing the service (Oraclize, RealityKeys), or having to make do with a prediction market (Gnosis, Augur) when it is not the right solution, but all of these introduce a single point of failure in decentralized systems, one that you must trust will give your smart contract good data to work on.
A proposed solution to this is a decentralized oracle network (DON):
1. requests for information are posted to the network,
2. Nodes in the network follow the request’s instructions to retrieve data
3. The consensus decides what the correct data is based on the number of people reporting it and their reputation in the system
4. Those who align with the choice are rewarded with reputation and the fee offered by the requester, those who do not lose reputation
If you see similarities to how other blockchains work, you are correct: this is not simply a service that integrates into blockchains, but a distributed network in its own right. There are no such networks currently running, though they are in the process of being built.
Oracles can be considered the key to the potential of smart contracts, by allowing blockchains to interface with the world itself. This can already be done by introducing a trusted entity, though it’s expensive and attaches a single point of failure to the smart contract; technology however seems to be moving towards a decentralized oracle network such as WitNet to provide trustless and distributed oracles, that work independently of other blockchains, with their own incentive schemes.
Further reading (if you’re interested)
- Witnet – A Decentralized Oracle Network Protocol: https://witnet.io/static/witnet-whitepaper.pdf
- Truthcoin – Peer-to-Peer Oracle System and Prediction Marketplace: https://www.truthcoin.info/papers/truthcoin-whitepaper.pdf
Articles and other resources
- Setting up an oracle machine on Amazon’s AWS: https://bitcointalk.org/index.php?topic=301538.0
- Can oracles send data to smart contracts on multiple blockchains? https://ethereum.stackexchange.com/questions/7965/can-oracles-send-data-to-smart-contracts-on-multiple-blockchains
- How does Oraclize handle the TLSnotary secret? https://ethereum.stackexchange.com/questions/201/how-does-oraclize-handle-the-tlsnotary-secret/1636
- Why do we need a Decentralized Oracle Network? https://medium.com/witnet/why-do-we-need-a-decentralized-oracle-network-91ba455d074d
- Hardware Pythias – bridging the Real World to the Blockchain: https://www.ledger.fr/2016/08/31/hardware-pythias-bridging-the-real-world-to-the-blockchain/#.2zeggzh6f
- Focal point (game theory): https://en.wikipedia.org/wiki/Focal_point_(game_theory)
- Why Smart Contracts in Blockchain Need to Avoid Non-Deterministic Functions: https://dzone.com/articles/why-smart-contracts-in-blockchain-needs-to-avoid-n