The Oracle Dilemma

Discussing the risk of third parties becoming single points of failure, and the limitations in optimizing blockchain oracles for decentralization, security, and scalability.

Introduction

Blockchain oracles fetch data for Web3 applications so that smart contracts can use off-chain conditions to execute automated agreements. Oracles are named as such because they possess knowledge that a blockchain ledger simply can’t know. Blockchains simply track the native assets on their public ledgers. They don’t keep track of the weather or the price of a barrel of oil, or any other off-chain data, for that matter. 

To solve for this, oracles can step in and act as communicators, accepting requests for data and then aggregating and validating that data so that these processes can be automated. For instance, a token bridge which processes cross-chain liquidity needs data on the exchange rates between two assets, and needs the prices updated frequently to ensure that both parties are satisfied with their trades or swaps. This is particularly important during times of volatility. 

However, blockchains are often understood to be more robust than traditional systems by virtue of their decentralized nature. Ironically, this can be all but negated by relying on a third party which may or may not be as secure as the blockchain utilizing its services. Incorrect data making its way to an automated system can be disastrous, especially if it is allowed to exploit such situations undetected and for extended periods of time. 

Blockchain oracles thus open up opportunities to bridge blockchains and valuable use cases via interoperability, but pose a threat to users as potential single points of failure. In the case of a network generating public and private keys, for example, there are security risks throughout the process, not to mention the distribution of public keys. 

As mentioned, if there are any flaws in the process, they represent massive risks to the security of the smart contracts (and all the assets) which rely upon oracles. The most salient challenge for developers basically boils down to achieving seamless interoperability amongst ecosystems without compromising the security of the underlying consensus layers and the relevant on-chain assets. 

This is why optimization is so difficult, and why developers are destined to struggle with making certain tradeoffs and building clever solutions to safeguard any potential weak points along the way based on how those tradeoffs play out over time after adoption, and as their projects scale. This article aims to introduce these concepts and discuss why it’s perfectly reasonable to be optimistic about the future of blockchain oracles and their contributions to interoperability in a multi-chain world.

CAP Theorem

To first understand the oracle problem, let’s trace the history a bit. Brewer’s theorem, also called CAP theorem, was named after Dr. Eric Brewer (of MIT and now Google) after he made the conjecture that distributed systems must choose two of the three following characteristics: consistency, availability, and partition tolerance. Nick Szabo continued this work in 2001 by making the case that the disadvantages outweigh the advantages.

CAP theorem claims that it’s impossible for distributed systems to provide all three of the following properties simultaneously:

1. Consistency: Every read operation receives the most recent write.
2. Availability: All non-failing nodes in the system return responses for every read and write request within the allotted time.
3. Partition tolerance: The network remains functional despite partial failures or delays in communication between nodes.

When prioritizing consistency over availability, operations will execute in a timely manner or else be rejected as failed transactions. When opting for availability over consistency, operations might get stuck processing as requests continue waiting for enough signatures from nodes to be processed. That is, the network continues processing requests until the non-failing nodes return their responses. Certain levels of partition tolerance must be maintained or else the network experiences fatal errors sooner or later.

CAP Theorem was the predecessor for the blockchain trilemma, which set the stage for the oracle dilemma, as developers have designing smart contracts to interoperate with off-chain data.

You see, public blockchains manage distributed networks of independent nodes to achieve consensus over their shared ledger, including each additional block, remain resilient to Byzantine behaviors, and settle transactions in a timely manner. This not only takes time, but a clever incentive structure which rewards honest behavior, prevents malicious behaviors, and doesn’t cost users too much in gas fees. 

Take Bitcoin for example: while the network is pretty decentralized and secure (since each block is processed synchronously by the entire network), it is only able to process approximately seven transactions per second (TPS). This means that transactions settle much more slowly, meaning network availability is lower than what other blockchains can offer their users.

Brewer’s theorem has most recently been extended to become the basis for the much-discussed Blockchain Trilemma, which states that it is impossible to build a blockchain protocol that excels in more than two of the following qualities: decentralization, security, and scalability.

The same concepts are further extended to apply to data feeds coming on and off-chain in that the ultimate guardian and validator of the data’s fidelity, called the oracle dilemma. Let us say it extends the Blockchain Trilemma to include the notion that a chain is only as strong as its weakest link.

Blockchain Trilemma Extended: The Oracle Dilemma

The “Oracle Dilemma” is a shorthand description of the challenges and tradeoffs faced by smart contract developers when calling upon third-party applications in order to scale their utility past the siloed ledgers of their respective blockchain platforms. Given that blockchains are meant to be decentralized and kept honest by a native system of cryptoeconomic parameters which incentivize the desired behaviors and performance outcomes.  

The primary issue is that smart contracts using third-party oracles rely on external data, such as the price of a non-native, off-chain asset or the outcome of a sporting match. However, the fidelity of the data must be validated at the sources by an oracle, meaning the blockchain’s security is only as secure as the oracles upon which they rely. 

That is, the oracle might have poorly-designed security parameters, a centralized node architecture or consensus mechanism, a lack of entropy regarding the selection of block leaders during the validation process, etc. This could make a perfectly decentralized blockchain into a centralized nightmare via exploitable weak points like centralized or improperly calibrated oracles.

Colluding nodes could inject false data, cause erroneous contract executions, and undermine the integrity of blockchains.

The so-called “dilemma” arises from the tension between the desire for external data to be readily available as inputs into smart contract agreements for near-instant settlements, and the responsibility inherent to the oracle at the nexus, as it validates and delivers the data on-chain. 

However, they could and have been exploited as single points of failure, allowing certain nodes to front-run or manipulate the ordering of transactions and delivery of data in order to make advantageous trades for themselves. This has so far posed a problem because the ethos of Web3 is decentralization, which is clearly at odds with the status quo regarding blockchains and their oracles.

The Status Quo is Sub-Optimal

While incumbents offer comparatively more decentralized oracle networks by way of their architecture, there are also some criticisms of these protocols. Here are a few of the most relevant critiques:

1. Centralization: Incumbent networks are not fully decentralized, as they rely on small numbers of “trusted” node operators to provide data to the network. The primary mechanism for keeping them honest is a rudimentary reputation system which identifies outlier values reported to the aggregator smart contract. The simplicity of their node architectures and consensus algorithms leave the network vulnerable to Byzantine behavior like node collusion, MEV exploits, frontrunning transactions, and other manipulations.
2. Security: The primary concern with incumbent oracles is that the nodes within the protocol must be trusted, and the ability of malicious actors to game the system left up to the nodes’ propensity to risk damaging their reputations for profits. While this seems reasonable on the face of it, it simply doesn’t scale properly. Systems must be in place which assumes that some nodes will attempt to game the system for their own advantage, and effectively introduce entropy (randomness) into the process which circumvents Byzantine behavior without the need to rely on trust. This is especially true as the network grows and more time passes. 
3. Cost: The pricing model and cost of using some networks can be relatively high, particularly for startup projects looking to bootstrap their operations. They are faced with limited functionality or unfeasible economic costs. Some have argued that poor pricing models for oracle services could limit the adoption of Web3 more broadly as functionality would remain relatively limited.
4. Scalability: Most oracles are perfectly capable of delivering secure data within a limited scope of utility and usefulness. Unfortunately, that is not how you optimize for maximum scalability and interoperability amongst digital asset protocols. If they are limited in their ability to support the needs of large-scale enterprise applications, then they are ultimately destined to fail or be relegated to niche use-cases. The way forward instead should be to invest our time and energy in networks which maintain strong fundamentals when it comes to scaling operations.

Even the most well-known oracles have not been immune from exploits, and we believe that investors would like to know that further exploits are averted before they happen rather than patched after their funds are lost. Even in best-case-scenarios in which funds are completely recovered, hacks are not enjoyable (aside from the litigators) to go through as they tend to be both lengthy and costly.

A Few High-Profile Oracle Exploits

While not all oracles have proven themselves untrustworthy by falling victim to attacks, if they are susceptible to them at all it is reasonable to assume that devastation is all but inevitable. That is, whether the problem arises sooner or later, it will happen eventually. Oracle designs that fail to prepare for this inevitability are ultimately destined to fail, unfortunately.

The same can be said for node participants and validators in that whether or not they have colluded to gain advantages over others in the network now, game theory suggests that some will try eventually. This is especially true as the network scales; it is therefore most prudent to anticipate the danger before it arrives to ravish the project. This is why centralized oracle solutions are unacceptable and should be disregarded except for the wisdom they can leave us with as relics of the past. Unfortunately, several major exchanges operate in just this way, with centralized oracles. 

Though this may surprise some, even well-known projects like Chainlink have experienced major exploits in the past. The first exploit of Chainlink oracles occurred in 2019 when someone was able to drain around 700 ETH tokens from several node operators by spamming several nodes and then selling CHI gas tokens during the resulting increased demand for transaction fees. To improve upon this, networks should introduce more entropy into the process so that nodes become less susceptible to identification and exploitation.

More recently, the Mango Markets hack saw an oracle exploited, costing the protocol over $100 million in damages. The oracle was essentially tricked into reporting that the MNGO token was trading at a higher price than it otherwise should have been. This caused mayhem on the protocol as it caused a number of transactions to execute, like liquidating collateralized loans. If fallback security parameters had been set to recognize faulty oracle price feeds, the devastation could have been prevented. 

While these are unfortunate events, they nevertheless served to inform us on how to best approach the provision of oracle services in the safest ways possible. In other words, newcomers to the space have learned from the mistakes of others, and are implementing much more robust sets of performance and security features, and even inventing new smart contract languages which will result in better outcomes. This ultimately drives adoption to the next level as utility expands, the overall sentiment around Web3 products improves, and fears of the unknown begin to wane.

Solving the Oracle Dilemma

To mitigate such concerns, protocols have begun to implement additional safeguards like the combined use of multiple oracles for redundancy, various attempts at decentralized oracle networks, fallback mechanisms, and other trust-minimizing primitives like zero knowledge proofs. The use of more advanced smart contract programming languages also helps shore up security risks.

Furthermore, introducing more efficient node architectures, consensus mechanisms, safety procedures, and other performance-enhancing primitives will solve the oracle dilemma. Additional features like privacy protections will allow for even more nuanced oracle services and use case propositions. 

Ultimately, to solve the oracle dilemma is to solve the blockchain trilemma in terms of the oracle’s consensus mechanism and security parameters. That is to say, an oracle that adheres to or surpasses the security standards of a given blockchain is what’s necessary to ensure that assets on a given protocol remain safeguarded. Supra offers its stack of Web3 solutions with this concept at the heart of every design.  

For a summary of how Supra’s tech addresses the oracle dilemma, check out our Distributed Oracle Agreement Litepaper or the full DORA whitepaper for you devs out there. Additionally, readers can find additional Supra whitepapers here. 

References

1. Albizri, A., & Appelbaum, D. (2021). Trust but verify: The oracle paradox of blockchain smart contracts. Journal of Information Systems, 35(2), 1-16.
2. Caldarelli, G. (2020). Understanding the blockchain oracle problem: A call for action. Information, 11(11), 509.
3. Egberts, A. (2017). The oracle problem – An analysis of how blockchain oracles undermine the advantages of decentralized ledger systems. Organizations & Markets: Policies & Processes eJournal.