Understanding oracles

This post is to discuss about what we think oracles really are and to cover some common misconceptions around the matter.

To us an oracle is a third party you have to talk with when you need some data you don’t want to (or you cannot!) fetch by yourself. The reasons for this can be many.

On one side, you might not trust a single entity while signing your Bitcoin multi-signature transaction. Let’s say for example that you want some funds to be moved just under certain conditions. Instead of doing this on your own (which doesn’t give any guarantee to external parties) or delegating this to a third party (which you don’t want to put the trust in, as he could behave badly), the Bitcoin-way to enforce your logic is to split the transaction approval process to different signing parties (oracles?) via multi-signature transactions.

The way to leverage N-of-M multi-signature transactions is to ensure each oracle owns just one private key so that he can put one signature whenever he thinks its the right time to do so, but the transaction will be valid just once N-of-M oracles will have a consensus on which transaction to sign. This is much stronger than trusting a single external party since the chosen oracles might be competing ones and with a low change of being all fraudolent.

The idea of having a distributed oracles network has been there since years, however finding a consensus on an inter-oracle communication protocol (Orisi attempt?) is hard. Finding parties willing to join that network is even harder since a good incentive process needs to be in place and a proper design on how to interact with this oracle network is something there is still not a consensus on. Other than this, a major limitation can be the data-source you want to use to get your data — some of these might not be available without permission to external parties (we’ll talk more in deep about this later).

While talking about smart contracts (Ethereum) the idea is much different, your transaction approving logic is enforced by the network via your own smart contract code. This means the oracle is not putting a signature once some conditions are verified, but instead he is providing to you the data you asked for — the conditions can be verified on your side directly and trigger any transaction or status change. Still you cannot rely on a distibuted network to get external data: applications/services executed on-chain live in their own walled garden, so you need oracles to throw external data in.

The growing need of data is just the result of a growing industry looking for more and more complex real-world use cases. However, most of the misconception around oracles is caused by a weak definition of what kind of data you might want an oracle to get for you.

For example prediction markets like Augur or Gnosis are meant to give a good and reliable indicator of the evolving sentiment (or knowledge!) of the crowd around future facts. Prediction markets are often referred to as oracles but in a broader and much different sense than the one discussed above.

Another point worth discussing is the following, do we want to call oracle what is just a price feed? That is just a data-source and most of the times it won’t have any connection with blockchains. Financial institutions often refer to “Bloomberg” or “Reuters” as oracles, but what they really mean is using them as data-source. Being the oracle brings with itself all the complexity of interfacing to blockchains, which is something data-sources have no interest in doing directly (extra complexity and costs). Still, an oracle could give access to Bloomberg data once the appropriate data-source and formula are chosen. Referring to those provides as “oracles” instead of “data-sources” is mostly yet another misuse of the term.

To make this more general, we can define 3 entities:

• data-source
• query
• the oracle/oracle network

As for the data-source, this is the source of the information you are looking for, this can be anything depending on your actual query, some examples can be “Augur” (while looking at future events/facts), “Bloomberg” (while looking for financial data), “Bitcoin blockchain” (while looking for an address balance, a given transaction OP_RETURN content or any other blockchain data), “WolframAlpha” (while looking for the response to a given Wolfram Alpha query) or.. “Web”? Getting web data-feeds or APIs data is both the most simple and common place were you want to get some data from.

The query is a formula the data-soure you have chosen can understand in order to give you back the data you want.

The oracle/oracle network is the party in charge of connecting you to the data-source.

The two points worth discuss here are the following.

1. Why would I trust a data-source? Most of the times you shouldn’t. Finding a consensus on different data-sources is a good way to go and gives you extra reliability while still using somehow “centralized” (useful) data.
2. What if the oracle/oracle network gives me back a wrong result? This is the main point around preferring to use an oracle network consensus instead of a single oracle. But wait, isn’t there any other way to prevent the oracle to tamper data? We’ll discuss about this in a bit.

The Oraclize approach in being an oracle is different.

You can look at this like something in between the single oracle and an enhanced oracle network. Oraclize could potentially avoid giving back to you a response (for law-enforcement reasons or for downtimes), but cannot alter the data coming from the data-source you have chosen.

This is why we refer to our service as “provably-honest”. The way this is possible is thanks to TLSNotary/pagesigner. It’s a modification of TLS which is used by our oracle service to provide cryptographic proofs showing that the data we provided to you was really the one a given server gave back to us at a specific time. Other than providing this proof, Oraclize is distributing the proof across the permanent web. Being also part of the IPFS persistence consortium our proofs have a good chance to be available even once our system is unreachable (for any reason).

We do provide tools to verify our honesty independently. This is for example our network monitor for Ethereum, which is connecting on your client side (this is why it’s so heavy, sorry about that!) to public Ethereum nodes and IPFS gateways (or to your own if you want to) to look for Oraclize transactions, fetch their TLSNotary honesty proofs and verify them.

You can easily monitor the network by yourself to ensure Oraclize is behaving honestly and we really want to encourage you to do that!

What does this mean in practice? If we do alter your data, anybody can verify this at any time, automatically and in a jiffy, our reputation would be broken. If having a one time bad reply still sounds to you as too risky, you probably want to wait for us to release the opensource on-chain proof verification code for Ethereum that we are working on. This means that your smart contract code can verify the TLSNotary proof on its own while receiving the data from Oraclize so that this data is discarted if the proof turns out to be invalid!

In our opinion Oraclize is a good compromise to solve “the oracles problem” in a way which works today and does fit with decentralized blockchains and smart contracts. Having an oracles network would help addressing the “censorship/downtime” issue, but the risks involved in relying on a single oracle only are drastically reduced by the new approach Oraclize is implementing.

Thomas Bertani

Note: The company has now rebranded into Provable.