The Ideal Decentralised Oracle Network
From the Community - 2021-01-29
As we move further into 2021 there are multiple oracle solutions for platforms to use, all of them containing different features, design choices, and various approaches to solving the oracle problem. In this blog post we are going to walk through some design choices taken, discuss what the ideal decentralised oracle network looks like, and why it’s important for one of them to become the standard for all blockchain integrations.
Blockchain Oracles and the Oracle Problem
An oracle is a blockchain middleware that creates a secure connection between smart contracts and various off-chain resources for the purposes of communication or sharing data. By taking this idea and extending it to a decentralised oracle network, a blockchain is able to interact with the outside world in a decentralised way, expanding the security and tamper-proof guarantees offered by on-chain smart contracts. This method of decentralisation at the data delivery layer is an attempt at solving the oracle problem, and is the sole purpose of an oracle network. The only reason oracles exist and are needed is because of this one limitation of blockchain technology.
One Network to Rule Them All
There are now dozens of different blockchain platforms, all with different features, consensus mechanisms, levels of decentralisation, and security designs. Blockchains have many different potential uses, and because they’re a closed-off system essentially living ‘in their own world’, it is natural to expect different designs that cater to specific use cases or prioritise certain features over others.
However, unlike blockchains, oracles do not live ‘in their own world’ separate from everything else. They are literally the communication layer between blockchains and the outside digital world, and allow blockchains to connect and communicate with things such as external systems, applications, other blockchains, APIs, and databases. So while they’re technically a layer of infrastructure, they can also be thought of as a communications protocol.
For many years now, TCP/IP has been the standard set of communication protocols for devices to communicate with each other over the internet. Because their entire purpose for existing is to allow network devices over the internet to communicate, a single standardised solution was needed and has now been adopted worldwide. Oracle networks are similar to TCP/IP in that they only exist to solve a communication issue (between blockchain and other systems). So, similar to how TCP/IP has been adopted as the single set of communication standards for the internet, a single, flexible, permissionless oracle framework should be adopted as the standard way for blockchains to communicate with the outside world. Standardisation of the oracle protocol layer decreases the time needed to integrate blockchains to other systems and APIs, and also removes the need for various oracle clients - which only adds friction and complexity to dApp development as well as introducing various attack vectors.
Blockchain Isn’t Always the Answer
There are a number of decentralised oracle projects that have come about that use an actual blockchain as their oracle network. This isn’t an ideal design for a decentralised oracle network. Remember our first point that the sole reason oracles exist is as a byproduct of the way a blockchain works? It doesn’t make sense to then take this same design and then apply it to the oracle layer as well.
To add to this, it introduces a higher level of complexity at the oracle layer, with consensus mechanisms and block creation becoming the main focus of the network instead of data delivery or communication between on and off-chain resources. In addition to this, there is a high level of data redundancy with an ever-increasing chain size. Remember, the sole reason oracles exist is to allow blockchains to communicate with the outside world. Are consensus mechanisms and storing an immutable chain of every single interaction really required to solve this issue? In addition to this, having a chain of data at the oracle layer introduces ‘multiple versions of the truth’, where different systems both act as a system of record. One of the main advantages of blockchain technology is the potential to reduce data redundancy, not increase it.
Finally, in these blockchain-based designs, the end-user has no control on which nodes in the network are used to communicate with the outside world. The protocol often requires that all nodes make the same request, or a random selection of nodes make the request. Providing end-users with a choice of which oracles to use for a given interaction is an extremely important aspect of a decentralised oracle network, with many businesses and data providers having their own requirements about where and how data can be shared.
Not Everyone Wants to Run a Node
It is a perfectly valid scenario for data and API providers to run their own node in an oracle network, essentially cutting out the ‘middleman’ third party oracle, and opening up new revenue streams by selling their data directly to smart contracts and decentralised applications.
However, not all data providers will want to run their own oracle nodes. Typically, data providers offer products where they allow access to their APIs based on a subscription and then leave it up to the people and companies that subscribe to their APIs to then integrate the data to other systems. This is especially true for providing data to blockchains, which is still a relatively new and niche technology. Not all data providers will want to earn, own or sell cryptocurrencies either, so the ideal decentralised oracle network can’t assume they will all be happy to earn income in the form of cryptocurrencies.
In addition to this, running an oracle node isn’t a trivial task and requires knowledge of DevOps and an investment in resources to ensure uptime, reliability and redundancy. This is especially true in scenarios where stake may be held by nodes and downtime can cost reputation and income. There is no such thing as ‘run and forget’ infrastructure; all programs and systems that run in a production environment require monitoring, auditing, testing and maintenance.
Once again, flexibility is key. The ideal oracle network should offer data providers the ability to run their own oracles and directly sign and sell data to blockchains and smart contracts, but it should also provide the option for permissionless third-party oracles to take on the task of running oracle nodes and on-sell the data they procure from data providers.
Keep it Simple and Flexible
As previously mentioned, flexibility is very important. Being able to access any API or system is absolutely necessary for the ideal decentralised oracle network. Most of the world's data is locked away in private databases and systems. The ideal oracle network needs to be flexible enough to be able to connect and access any of these, whether via a RESTful web service, database connection, CSV file, etc.
Some may say the simplest solution is to simply incorporate oracles into the base blockchain layer, and not have a separate oracle network with its own token. However, this is not an ideal solution for various reasons, as outlined by Ethereum’s creator Vitalik Buterin.
Staking Ain’t Easy
Staking is a topic often raised when discussing decentralised oracle networks. After all, an oracle putting ‘skin in the game’ to provide correct data seems to be a sensible feature of a decentralised oracle network, with some platforms already offering staking services live in production today.
However, staking is no trivial task and requires a lot more than simply the design and deployment tasks. It is a complex feature with many different scenarios and possible outcomes that delve deep into crypto-economic incentives and game theory mechanics. Ari Juels, Chief Scientist of Chainlink Labs states: “Previous works in this area haven’t modelled the full range of possible bribery attacks''. The ideal decentralised oracle network needs to have a carefully and thoughtfully designed staking solution, with a focus on robustness that takes into account all possible scenarios. As a comparison, it has taken Ethereum years to design and implement the first phase of their staking solution.
Based on all the points discussed above, it becomes clear that the ideal solution to the oracle problem is to have a single, well designed heterogeneous oracle network that becomes the standard way that blockchains communicate with the outside world, much like how TCP/IP has become the standard protocol for devices to communicate on the internet today.
This standardised decentralised oracle network should not be a blockchain. It should allow users to choose which nodes are used for requests and it should be flexible enough to allow data providers or third parties to run a node. It should be robust enough to be able to access any API, system, database or interface, and it should have a carefully thought out and planned staking solution.
Like TCP/IP, oracles exist purely to solve a communication issue, so their design should be kept simple, flexible, and always adhere to the original reason for why they are required in the first place.