On decentralization of blockchain oracles (Part 1)

The concept of “blockchain oracles” has emerged to solve an inherent limitation of blockchain protocols: the impossibility for such decentralized networks (and the applications/smart contracts built on top of those) to interact with an external context. As blockchain applications were becoming more complex, a strong need to address the “walled garden” limitation emerged.

When blockchain oracles firstly came to life, different implementations of such system have been experimented with the aim of enabling a connection between decentralized applications and the real-world without breaking two key benefits granted by blockchain platforms: security and removal of open-trustlines with third parties. Attempts to implement an oracles network (the most notable being Orisi), where a large number of players act as a blockchain oracle reporting data from the outside world, have ended up failing. As an alternative, companies have proposed either a centralized approach requiring you to trust the data-carrier (i.e. Thomson Reuters) or a centralized approach where attestation techniques are used to reduce the level of trust at a minimum, while increasing the level of security.

Oraclize was the first proposing such second system back in 2015. Since then, other players (the most notable being Microsoft) have validated it by adopting a similar approach. Oraclize is the world’s most widely adopted blockchain oracle service, feeding every day on-demand data both to testing (available since 2015, millions of requests processed) and production (available since 2015, +400k requests processed) environments.

The topic of “decentralized oracles” has always been of interest for anyone approaching the smart contracts world. While such a solution would be ideal not to break the security model implemented by blockchain platforms, practically speaking it is impossible to have.

You cannot fix decentralized limitations by using a decentralized system.

As a variety of slightly different implementations of a blockchain protocol have come to life, none of those natively supports the oracle feature. If a decentralized architecture for oracles would be possible to develop, then there wouldn’t be a need for third service providers as the connection would be offered by blockchains directly.

There is a relevant difference between a decentralized system and a distributed one. A distributed architecture for blockchain oracles is not the ideal solution, but it helps in reducing the attack surface and to avoid single points of failure (and practically speaking it can be implemented!).

Our aim at Oraclize is to keep improving the system behind our blockchain oracle in order to implement the best solution possible to overcome the “walled garden” limitation. A brief recap of the main pillars underneath the Oraclize solution follows:

• on-demand data — provides data to DApps while avoiding unnecessary spam of the network (available)
• access to any Web API — enables the smart contract to decide which source to trust for the data. Oraclize wants to provide a secure connection for data-transport, not giving guarantees on the quality of data (as we cannot check the quality of data for each data-generator available on the Internet) (available)
• authenticity proofs — cryptographic guarantees proving that a data was not tampered with. Those are based on a variety of attestation techniques: the trust is being moved from the data-carrier to the “attestator” (aka the provider and/or manufacturer of the attestation technique on top of which the authenticity proof is based)(available)
• multiple technologies (and attestators)— thanks to authenticity proofs being based on a variety of attestation techniques (different technologies + different technology-providers), the overall security of the system is improved and there is no single point of failure (available)
• on-chain verification of authenticity proofs — enables smart contracts to verify the authenticity of a data before using it and eventually avoiding its use in case the data would result compromised (first version available)
• distributed architecture — reduces the attack surface as the blockchain oracle service is supported by a variety of machines hosted by multiple parties. Oraclize already implements an internal distributed architecture and is working now on publicly-available machines (coming soon)

Note: The company has now rebranded into Provable.