Smart contracts once promised to bring us a world without rent-seeking middlemen, where Code is Law, and trust is enforced by math and blockchain consensus. While substantial progress has been achieved, the initial vision of a truly trustless system hasn’t been realized.
The nature of the oracle problem is best illustrated through a simple example like an oracle finding the current BTC/USD price. The traditional solution of taking a set of data points, removing the outliers, and using the median only works until it is attacked. If there is only a nominal cost to submitting a data point, an attacker can simply flood the chain and move the average or median in any direction. An oracle using this simple aggregation model can, if attacked, report that 1 Bitcoin is worth $10. Smart contracts will then consider this to be the correct price.
As more money is betting on outcomes determined by an oracle, attackers have more incentive to corrupt the data. One way to mitigate this is to limit the amount at stake. This works in theory, but it completely ignores off-chain bets. After making giant off-chain bets based on the outcome, an attacker can spend what looks like inordinate amounts to corrupt the oracle, when in reality it is just a fraction of what would be gained.
A complex system of dual currencies, stake-weighted voting, and dispute resolution protocols can mitigate many of these vulnerabilities. The issue is that such a system quickly becomes too complex, meaning a single implementation bug could derail it.
How Projects Are Solving The Oracle Problem
There are several approaches that projects are taking to solve the oracle problem. As this post outlines, each one has clear advantages and disadvantages. Some require a high degree of trust, while others are more trustless.
It’s crucial to point out that all oracle solutions ultimately strive to ensure that reporters remain honest and only validate data that is valid. Before we explain the ins and outs of Komodo’s own oracle solution, let’s examine some of the industry’s most respected solutions from a high-level.
Chainlink
Chainlink’s solution involves a set of trusted feeds. Reporters (or oracle providers in this case) can be organizations or individuals. Chainlink’s oracle solution is considered to be centralized, which presents security challenges. Reputation monitoring helps determine which oracle providers are selected for data feeds that flow into smart contracts. This design is relatively straightforward, with oracle providers with better reputations generally being more trusted to validate data. The issue is that Chainlink lacks incentives and disincentives needed to prevent “retirement attacks”, which involve a reporter with a good reputation (and hence more responsibility in data validation for smart contracts) suddenly deciding to become corrupt before going offline.
Augur and Hivemind
Although Chainlink reporters aren’t incentivized to accurately validate data, Augur and Hivemind are two projects which have such incentives in place. On both prediction markets, all reporters are also required to stake tokens. Honest reporters are rewarded with REP and HIVE tokens, respectively. Additionally, dishonest reporters may lose their stakes for being dishonest about their observations of event outcomes. The combination of incentives and disincentives as well as the decentralized nature of these networks reduces the likelihood of such a scenario. Nevertheless, it’s still possible for a group of dishonest reporters to collude and execute a bribe attack simply by out-voting honest reporters.
Amoveo
Amoveo’s oracle solution introduces a design that is quite different from the above-mentioned projects. Amoveo runs on its own blockchain network and re-uses its existing consensus mechanism to secure the oracle. This solution is similar to Augur and Hivemind in that it uses incentives and disincentives, with a few key differences. Data validation is determined by the total number of reporter votes on those networks. Meanwhile, Amoveo uses the total amount of bets from reporters. In other words, reporters can bet how much VEO they want to risk on data validation decisions. Since there are potentially much higher amounts of funds at stake, reporters should theoretically remain honest. However, it’s possible for a small group of dishonest reporters with significant funds to coordinate an attack.
jl777's Oracle Proposal
Komodo Founder jl777’s oracle proposal applies many of the ideas introduced by Amoveo’s oracle. For example, jl777’s solution also relies upon consensus mechanism re-use and runs on its own chain. However, there are a few key differences. Nodes on the Amoveo network typically don’t need to worry about oracles, except for in extreme cases. In contrast, nodes on Komodo’s network are required to participate in finding and recording the outcomes of all oracles, avoiding the need to implement escalation mechanisms. jl777’s oracle proposal has led to the research and development of a decentralized trustless oracle (DTO) solution called the Komodo Trustless Oracle.
The Komodo Trustless Oracle
With our solution, each block needs to include the external data point, which then becomes part of the consensus mechanism itself. As mentioned above, every node on the peer to peer network must recognize and agree upon every external data point. We also introduce a tolerance level of 1%. In other words, the change in the data from the last block must be within a range of plus or minus 1% for the network to accept it.
Using the price feed example, the process to update and validate the current BTC/USD price is simple and straightforward:
- Each node updates their local price invoking a function built into the coin daemon itself, fetching the data from a few different public sources (e.g. Coinbase APIs). This is done by all nodes, not just mining nodes. This ensures that all nodes have a relatively recent, and somewhat different, price locally. The price polling is done at half the block time.
- In the process of constructing the blocks, miners check if the data is within the tolerance range. The price is then recorded in the block itself.
- Finally, all nodes during block validation invoke a function to verify again that the price data is within the tolerance level of 1%.
If you are interested in learning more about the in-depth technical details, we have covered them in a separate blog post.
It’s important to understand that the BTC/USD price could certainly move outside of the set tolerance level during one block. In a real-world scenario, the price reported by the oracle would lag slightly behind the actual price during times of extreme price volatility. Fortunately, this isn’t an issue for the overwhelming majority of possible use cases (e.g. daily settlements, weather data, or traffic data) for the Komodo Trustless Oracle.
The Right Way of Securing an Oracle
Security is one area where the Komodo Trustless Oracle module strives to provide drastic improvements over existing solutions. The 1% tolerance rule might sound arbitrary and counterintuitive at first but actually secures the chain in an elegant way, without any added complexity.
Scenario 1: A Basic Attack
Let’s take a typical attack scenario, where the attacker wants to push the price as high as possible. The attacker mines a block with the maximum price possible, 1% higher than the current price. Miners have slightly different local prices, as they get the data from different sources at slightly different times. Some will accept this block since the attacker’s price will fall just below the allowed 1% tolerance level, and some won’t accept it. This creates a small fork on the chain. However, when the attacker tries to submit another 1% higher price in the next block, all nodes will reject it as invalid. As a result, the attack is stopped just as quickly as it started. The nodes that went on the one block fork will return to the main chain when the next honest block is mined.
Scenario 2: An Advanced Attack
Let’s consider a much more extreme attack scenario. Suppose an attacker invests in a fake chain, increasing the price block by block, with a 1% increase each block. This would be rejected by all the online nodes, but there is a risk that nodes just coming online would accept it as valid (since it follows the 1% rule). This security challenge is solved with the notarizations performed by Komodo's Notary Node network. Notarizations are used with features like delayed Proof of Work (dPoW) security and Platform Synchronizations.
After the notary nodes all agree on a recent blockhash (after the small reorgs), a notarization is submitted to the peer to peer network for validation. All the nodes validate the notarization, if and only if they already had the identical blockhash for the corresponding block height. This record is made permanent on the Smart Chain, the Komodo chain, and finally on the Bitcoin chain. The only way a notarization can happen is if all the notary nodes, which are always online, are in agreement. This allows new nodes coming online (bootstrapping) to differentiate between a fake chain and the honest chain.
Other Attack Scenarios
There is only one purely theoretical attack that has a chance of working. In this scenario, an attacker would need to create a fake chain and control a vast majority of notary nodes. Even if such an attack is successful, it would only create a chain split among the nodes that were not online. Such a chain split would be detectable automatically, and the community could be promptly informed if an attack was in progress.
Conclusion
Although the Komodo Trustless Oracle module is still in the R&D phase, it aims to offer a better solution to the oracle problem. That’s because the jll777 oracle proposal asks the right question, “How can we make data part of consensus itself?” Instead of spending time and effort on issues that can’t be reliably solved (e.g. how to ensure data isn’t compromised in transit), Komodo developers are focusing on securing the chain itself.
The Oracles Antara Module is still in development but already works as a proof of concept. It can be used by itself or as the basis of sophisticated blockchain applications, like the Pegs Antara module, which lets developers create algorithmic stablecoins and other blockchain-based financial instruments on demand.
Other powerful modules available include tokens, Dilithium quantum security, instant micropayment channels, gateways between different blockchain platforms and protocols, and much more.
Join us as we continue to lead the blockchain revolution.
📧Komodo Newsletter
If you'd like to learn more about blockchain technology and keep up with Komodo's progress, subscribe to our newsletter. Begin your blockchain journey with Komodo today.