Enabling integration with external data sources is considered by many the most important challenge for the mainstream adoption of blockchain technologies. In enterprise environments in which data is spread across thousands of heterogenous systems, no blockchain platform have any hopes of being successful without providing seamless integration models to access those data sources. Paradoxically, this problem remains relatively ignored compared to other aspects of the blockchain ecosystem.
In blockchain architectures, we use the term Oracle to the entity responsible from accessing external data without violating the integrity of the blockchain. In ancient Greece, oracles were sacred people that interpreted the will of the Gods and relay it to the population. The most important oracles of Greek antiquity were Pythia, priestess to Apollo at Delphi. One of the most famous prophecies of Pythia was when King Croesus of Lydia (modern-day south-western Turkey) asked the oracle whether or not he should go to war on his neighboring kingdom. The oracle replied that if he went to war, a great kingdom would fall. Croesus interpreted this as being his enemy’s… it turned out to be his own. A reminder that correctly interpreting the information from the Oracle is as important as having access to the Oracle itself 😉.
Having established an analogy in which the Gods are the external data sources and the mortals are smart contracts 😉, the role of the Oracle is to bridge those two worlds without violating the state integrity of the blockchain. The concept of Oracle has been present in many blockchain platforms since the early days of Ethereum and yet, the problem remains largely unsolved at scale. Part of the challenge is that most Oracles introduce a level of trust that directly contradicts the trustless nature of the blockchain. This is what I like to call the “Oracle Paradox”
The Oracle Paradox
To understand the Oracle Paradox, it might be helpful to start by providing a basic taxonomy that represents the different types of Oracles in the blockchain ecosystem. Following the different channels in which external data can be integrated into blockchain applications, we can come up with a basic categorization model for the different types of Oracles.
· Human Oracles: These are Oracle models in which there are people who access and enter external data signals into a blockchain.
· App Oracles: These are Oracle models based on software applications that contain data required in blockchain applications.
· Centralized Oracles: These are Oracle models that rely on information from a centralized application.
· Federated Oracles: These are Oracle models in which the external information is validated by a small number of nodes related to the main data provider.
· Decentralized Oracles: These are Oracle models in which everything from the selection of the Oracle to the validation of the information is achieved using decentralized consensus protocols.
· Hardware Oracles: These are Oracles that rely on Trusted Execution Environments(TEE) to isolate code that access external data to the blockchain.
I used a color scale to denote the degree in which the different types of Oracles are vulnerable to the “Oracle Paradox”. Generally, human and hardware Oracles are relatively safe models to access external data while all the other architectures are somewhat vulnerable to the “Oracle Paradox”. In essence, the “Oracle Paradox” describes the friction between relevance of the external data and the level of trust that needs to be placed in the Oracle. Like any software applications, Oracles are vulnerable to bad behaviors that can materialize into gamified attacks in blockchains. In its simplest form, a centralized Oracle can decide to provide inaccurate data which can affect the behavior of blockchain nodes and make them vulnerable to an attack. Typically, the more decentralized the Oracle model the less vulnerable to the “Oracle Paradox”.
To address the “Oracle Paradox” challenge, some platforms have established financial, reputation and governance protocols that mitigate the vulnerability to bad Oracles. Recently, we have seen a new generation of Oracle protocols that extend the basic concepts of Ethereum’s Oracles to enable the implementation of very sophisticated external data access models.
Five Oracle Protocols You Should Know About
As I mentioned at the beginning of the article, Oracles remain an largely unsolved problem at scale and one that is becoming a roadblock in the mainstream adoption of blockchain applications. However, there are several protocols that have been actively innovating in the space helping and presenting creative ideas to enable the access of external data in blockchain applications. Here are some Oracle protocols that I think we should keep track of:
· Oraclize: Recently, I called Oraclize the most important blockchain protocol you never heard of . The platform provides a protocol that can integrate different types of data sources such as IPFS or URLs with blockchains like Ethereum, R3 Corda or BlockApps. Oraclize uses a mechanism called Authenticity Proofs to act as sort of an untrusted intermediary.
· ChainLink: Calling ChainLink an Oracle protocol might be an understatement. The platform acts as a decentralized Oracle network in which any participant can provide a data feed in exchange for LINK tokens. The ChainLink platform includes certification, validation and reputation services that enforces the integrity of the Oracles.
· Augur: Mostly known as a decentralized prediction marketplace, Augur has implemented one of the most sophisticated Oracle protocols in the blockchain ecosystem. Augur allows participants in a blockchain network to report external events relevant to specific predictions. The platform uses a validation-dispute protocol and reputation tokens(REP) to maintain a record of the behavior of the different Oracles.
· Aeternity: Aetirnity is a platform that enables the implementation of smart contracts that interact with external data sources. The platform relies on state channels to enable the integration of blockchains and external data sources. Aetirnity also includes a reputation system that serves as a currency for different Oracles.
· Rlay: A relatively new player in the space, Rlay provides a platform enables the formulation and validation of statements based on off-chain data sources. Rlay includes a Proof-Of-Coherence deterministic consensus protocol to validate statements from Oracles.
These are some of my favorite Oracle protocols in the blockchain ecosystem. Obviously, many of the major blockchain platforms that implemented their own Oracle protocols but, at the moment of this writing, none of them enjoys mainstream adoption. Solving the access to off-chain data remains one of the most important challenges for the next generation of blockchain technologies.