1.1 Oracle problem: A source-agnostic misinterpretation
Last updated
Last updated
Decentralization defines Web 3.0, which is characterized by distributing computation and settling outcomes through predetermined consensus rules. The business logic of a decentralized application is implemented as a smart contract, which runs on a blockchain-based smart contract platform. Decentralization allows participants to cooperate without requiring mutual trust or a trusted third-party, and thus provides robustness against attacks and censorship.
To enforce consensus rules, smart contract platform nodes have to verify that each contract invocation has resulted in the correct outcome by repeating the computa- tion locally. For this to be possible, smart contracts can only operate on information that is accessible to and agreed upon by all smart contract platform nodes. In sim- pler terms, smart contracts can only operate on the information that is readily available in the blockchain, and cannot interact with the outside world directly. This is widely known as the “oracle problem”, referring to an idealized agent that can deliver an arbitrarily defined piece of truth to the blockchain.
The oracle problem is ill-posed, as even its name suggests an impossible solution. An analogy would be to approach the problem of getting from Point A to Point B as the “teleportation problem”. Nevertheless, the first generation of solutions attempted to implement this literal oracle by posing a question and crowdsourcing its answer, which produces resolution times measurable in days and extreme gas costs due to the number of transactions that need to be made, which is not ideal for use cases such as DeFi or prediction markets. We must note that this approach is indeed suitable if the information to be delivered is subjective. A good example would be the resolution of a judicial dispute.
The second generation solutions narrowed their scope to only cover factual informa- tion that can be accessed programmatically, and ended up with the “interoperability problem”. In these solutions, an oracle node that is integrated to two arbitrary sys- tems (a blockchain and an API, two blockchains, etc.) acts as an automated inter- mediary between the two. Using multiple of these oracle nodes and settling on the outcome through predetermined consensus rules provides security guarantees that complement the underlying blockchain technology. These solutions are faster and less expensive compared to crowdsourced oracles, and consequently are viable for more use cases, yet they suffer from being designed around an over-generalization of the problem at hand.
Interoperability solutions involve three parties: API providers, oracles, and data consumers. However, they fall into the pitfall of modeling their ecosystem as being solely composed of oracles and data consumers, while ignoring where the data originates from. In other words, their models treat the oracle node as the mythical oracle that is the source of the truth. Being blind to one-third of the problem in this way results in impractical solutions to be perceived as feasible.
The interoperability solution being source-agnostic results in the following conse- quences:
• An intermediate layer of insecure and expensive third-party oracles, which could have been superseded by API provider-operated oracles;
• An ecosystem that nurtures rent-seeking middlemen, while excluding the ac- tual sources of the data;
• Indiscriminate treatment of data received from different sources in a data feed.
Another pervasive issue with interoperability solutions is that since they are low- level protocols, they regard the interface as a technical component, or middleware,rather than a complete product. As a side effect, the governance of the interface gets left out-of-scope. However, governance is hardly a trivial problem, because a decentralized interface requires independent and competing parties to cooperate. The currently utilized solution is a trusted centralized entity to govern the interface, which is at odds with the main objective of decentralization. The governing entity has full control over the output of an oracle network, which means a decentralized oracle network with centralized governance is a centralized oracle with extra steps.
