The Promise of Smart Contracts and the Oracle Problem

Torsten SándorApril 17, 2019

Self-executing smart contracts promised us a world without rent-seeking middlemen, where Code is Law, and trust is enforced by math and consensus. Why are we not there yet?

Today’s smart contract platforms suffer from serious issues. They are full of bugs and security holes (the Github of ConsenSys alone lists twelve critical Solidity vulnerabilities) and they are nowhere near scalable enough to support business applications. Of course, new technology is rarely perfect and things might become better over time.

The bigger issue is that blockchains are terrible at incorporating and handling external data points, and without external data, smart contracts can only work with what is already on-chain. This, in short, is known as the oracle problem. We need to solve this problem in order to accelerate mainstream adoption.

The Oracle Problem: Current Models Are Flawed

The Oracle Problem is well-known in the industry and there are many projects trying to build a decentralized and truly trustless oracle feeding external data into the system (Provable, Chainlink and Augur being the most prominent). However, these solutions all employ a flawed model.

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, and smart contracts will consider this as the correct price.

As and more and more money is betting on outcomes determined by an oracle, attackers have more and 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, but such a system quickly becomes too complex, and a single implementation bug could derail it.

The Komodo Trustless Oracle

The answer is not more but less complexity. The Komodo Trustless Oracle solves the problem in an elegant way that would be require a lot of time and effort to implement on any other platform.

The Komodo Trustless Oracle is a custom consensus module (CC-Oracles), where each block needs to include the external data point which becomes part of the consensus mechanism itself. We introduce a tolerance level of 1 percent, meaning that the change in the data from the last block must be within a 1 percent range to be accepted.

Using the price feed example, the process to update and validate the current $BTCUSD price is simple and straightforward:

  1. Each node updates their local price invoking a function built in to 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 the mining nodes, so all nodes have a relatively recent, and somewhat different price locally. The price polling is done at half the blocktime.
  2. In the process of constructing the blocks, miners check if the data is within the tolerance range. The price is recorded in the block itself.
  3. Finally, all nodes during block validation invoke a function to make sure again that the price data is within tolerance.

If you are interested in the technical details, we have covered them in a separate blog post.

The tolerance is set to 1 percent of the prior price, and it is indeed possible for the price to move more that this during one block. In a real-world scenario, the price reported by the oracle would lag slightly behind the actual price during extreme volatility, but this is not an issue for the overwhelming majority of the use cases (e.g., daily settlements).

The Right Way of Securing an Oracle

Where the Komodo Trustless Oracle really shines is security. The 1 percent tolerance rule might sound arbitrary and counterintuitive at first, but it secures the chain in an elegant way, without any added complexity.

Let’s take a typical attack scenario, where the attacker wants to push the price as high as possible. He mines a block with the maximum price possible, 1 percent higher than the current price. Miners have slightly different local prices, as they get the data from different sources at slightly different times. So some of them will accept this block, as it will fall just below the allowed 1 percent change, and some won’t. This would create a small fork on the chain. However, when the attacker tries to submit another 1 percent higher price in the next block, all nodes will reject it as invalid, and the attack is stopped just as it started. The nodes that went on the one block fork will return back to the main chain when the next honest blocks are mined.

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 percent 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 percent rule). This case is solved by notarizations. After the notary nodes all agree on a recent blockhash (after the small reorgs), a notarization is submitted to the 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 local 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.

There is really only one theoretical attack that has a chance of working: creating a fake chain and controlling a vast majority of notary nodes. But 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 can be informed that there is an attack in progress. This attack vector is purely theoretical.

Conclusion

The Komodo Trustless Oracle is the right answer to the oracle problem because it asks the right question: how can we make data part of the consensus itself? Instead of spending time and effort on things which cannot be reliably solved, like how to make sure the data is not compromised in transit, we focus on securing the chain itself.

The CC-Oracles module is under development, but it already works as a proof of concept (see the documentation here, and a simple dashboard reporting 55 different prices here). It can be used by itself or as the basis of sophisticated blockchain applications, like the CC-Pegs custom consensus module which lets developers create algorithmic stablecoins and other blockchain-based financial instruments on demand.