In our recent article, we touched upon the Oracle Problem. Today we are diving deeper into this topic, providing you with a comprehensive overview of what has already been done and what areas still need to be covered. Let’s begin!
Reasons behind the problem
Blockchains operate in isolated environments and are not naturally able to communicate with the outside world or other blockchains. This characteristic, apart from being a severe limitation, is also a crucial aspect of ensuring security. The oracle acts as a middleware solution whose role is to connect the blockchain with the outside world. It achieves that goal by providing all the data needed to build complex blockchain applications and enable real-life use cases.
This naturally revolves around financial aspects (i.e. creating tokens based on real-world data) but is generally applicable to a large spectrum of fields, from supply chain management to entertainment. At first sight, oracles may seem like a complete contradiction to blockchain principles. For instance, if a blockchain application requires data from a centralised source such as an oracle, then it can no longer be called decentralised. The trick here is to hit two birds with one stone — to be able to inject the real-world data onto the chain in a decentralised way that will not pose any risks to the application or protocol built on the blockchain. That is what the Oracle Problem is all about.
Defining The Oracle Problem
One of the first mentions of this term can be found in a Reddit Post from late 2014, an era before the Ethereum environment for smart contracts was launched. In the post, the author shares their thoughts on the lack of decentralisation in early applications of oracles. Certainly, a fascinating read from today’s perspective. A high-level definition of the Oracle Problem can be found in an article written by Jimmy Song:
There’s a need for the digital world to “know” about the physical world. This is known as the “Oracle problem”.
The “lack of external connectivity” of blockchains is also used as the basic definition in materials created by Chainlink, the biggest player so far in the oracle market. Brian Curran defines the problem more specifically as “the security, authenticity, and trust conflict between third-party oracles and the trustless execution of smart contracts’’. Therefore, the question we should ask in this context goes as follows:
How can a network prove to be genuinely decentralised when a singular entity controls its one genuine connection to the real world?
Because of that, oracles often become a single point of failure in many web3 projects. Solving the Oracle Problem is not possible without eliminating this issue. Another aspect of this problem lies within the design of the oracle ecosystem as the network must have a mechanism for resolving disputes. This is usually done by implementing a voting system between the nodes. Such systems however are vulnerable to bribes and collusion. We can safely assume that if in such a network, the potential reward of bribing nodes or colluding with them is greater than the cost, it will be used eventually. Therefore, even after making the system genuinely decentralised we still have to ensure its trustlessness. If the cost of frauding the ecosystem is always higher than the potential profit coming from doing so, we can call the network cryptoeconomically secure. In that case, to ensure this network is fraud-resistant, we do not need to assume the nodes are honest but that they simply are economically rational.
Areas to be covered
We can split solving the Oracle Problem into three major areas:
- Scalability — enabling oracles to process tens of thousands of transactions per minute without generating immense gas costs (The Data Latency vs Data Cost dilemma). The more frequently you need to fetch the data, the more you have to pay for it. In standard oracle solutions, the cost of fetching data at some point might even rise exponentially with increased latency. Proper scalability also means that the oracle is able to continue operation under extreme market conditions, such as the event known as Crypto Black Thursday.
- Incentivisation — designing the right incentive structure to ensure cryptoeconomic security. This has been a major design flaw of the leading oracle solutions pointed out by the critics for a long time now. No protocol has managed to solve this problem yet.
- Decentralisation — eliminating single points of failure. Ensuring that even if the malicious actors have access to the tech behind the oracle network (i.e. employees of the company) they still aren’t able to attack the network effectively.
No oracle provider has managed to solve the problem yet. That is why exploring new approaches and pushing the needle for innovation is crucial for ensuring the long-term security of DeFi and blockchains in general. That is what we, the team behind RedStone, are highly committed to.
At RedStone we are on a mission to build the next generation of Oracles. Our solution has an unrivaled ability to exert significant control over any new data listings. Result? The flexibility to follow any emerging market trends which, alongside significant cost savings, allows us to stay at the frontier of a new wave of Decentralised Finance.
Join us in the journey!
Twitter | Discord | Website | Github | Linkedin
