What is the Blockchain Oracle problem, and why does it matter?
Key Takeaways
- The Oracle Problem: isolated blockchains cannot access data from the ‘real world'.
- Blockchain oracles connect smart contracts to Web 2.
- Oracle Hotkey Risk: an oracle signs results on chain with their private oracle key, creating a significant hacking incentive.
- Oracle Operator Risk: the oracle itself can sign false, self-beneficial results to exploit the funds held on the smart contract.
- A gap in the market exists for supplying smart contracts with private data which cannot be exposed to the blockchain.
As the focus in the blockchain space moves towards tokenization, blockchain oracles can play a pivotal role in connecting isolated blockchain smart contracts to real-world data. This article sheds light on the Blockchain Oracle problem, the risks associated with oracles, and the mechanisms oracles use to ensure data feeds are trustworthy.
What Is The Blockchain Oracle Problem?
The Oracle Problem
Think of a blockchain network as an isolated computer not connected to the internet or any external devices. This isolation is an inherent property of blockchains and has created a market for supplying reliable, unbiased, and unmodified data to blockchain smart contracts.
In this analogy, consider a blockchain oracle to be a special USB drive containing valuable information and updates from the outside world. When plugged into the computer the necessary information is extracted from the USB drive which is then removed, maintaining the computer’s isolation. The computer must trust that the information on the USB is correct and untampered.
Blockchain Oracles
Blockchain oracles act as a bridge between smart contracts and web2 systems, transferring data in both directions. By pulling data from Web2 APIs, oracles enable smart contracts to execute based on previously unavailable data that lies outside the native blockchain environment.
Take the example of a smart contract that facilitates a lottery. A thousand players all stake $5, with each player assigned a number between 1 and 1,000. The $5,000 pot is held in escrow by the smart contract, preprogrammed to grant the winner withdrawal privileges of the funds. But how does the smart contract know which player won the lottery? Enter a blockchain oracle.
The blockchain oracle calls the API of a Web2 random number generator (RNG) in order to determine the winning number. The oracle will post the generated number on-chain, triggering the smart contract to grant withdrawal permissions to the winner. The on-chain assets will be transferred from escrow to the personal wallet of the winner.
Other use cases include but are not limited to stock prices used for DeFi transactions and identity verification by banks and governments for Know-Your-Customer (KYC). Given smart contracts handle billions worth of on-chain assets, it is imperative that the data they act upon is trustworthy and reliable from secure blockchain oracles.
How Do Blockchain Oracles Work?
A smart contract is essentially code deployed on a blockchain. And it is autonomous meaning once a smart contract is sent on-chain, by default the deployer no longer has any privileges over it. The aforementioned lottery scenario is an example of a smart contract escrow account. The critical issue is who to grant withdrawal permissions to i.e. which player can take the $5,000 pot. This must be assigned to the address of the winning player and the right to nominate a winner must lie exclusively with the oracle.
Having obtained the off-chain data an oracle verifies the data source and posts the results on-chain. This message to the chain is signed by the oracle’s private key. The smart contract validates that the holder of the private key, i.e. the oracle, indeed signed the message.
Why Do We Need Blockchain Oracles?
Reading this, you may be thinking, ‘Why don’t I push data on-chain myself?’ In short, you can. However, this comes with considerable limitations and risks.
Primarily, there is the issue of trust. Why should other stakeholders trust you? Self-signed data contradicts blockchain’s value proposition of removing the need to trust one entity or data provider. In the lottery example if the developer is providing the winning number they have significant incentive to enter the lottery themself and rig the result. Regarding private data, users would have to trust a developer with their private API keys or password in order to post data on-chain.
Furthermore, there is the oracle hotkey risk. The private key used to post data on-chain secures the value of funds at stake. If this key gets leaked or stolen the hacker can steal funds from the smart contract by posting fake results. A developer self-signing data is responsible for this key and subsequent risk. And depending on the terms of the smart contract, this developer may be liable for a proportion of lost funds.
What Are The Risks of Relying On Blockchain Oracles?
Trusting an oracle and the data it provides is the cornerstone of its value proposition. If an oracle is compromised, a smart contract will trigger state changes based on invalid data, leading to stolen or lost value.
Data Correctness Risk
Data correctness includes authenticity and integrity. Authenticity concerns whether the data was obtained from the correct source(s). And Integrity means the data reported on-chain has not been modified.
The Oracle Hotkey Problem
Parties that hold on-chain assets can keep their private key in a hardware wallet and retrieve it every time they sign a transaction. This is feasible as they transact relatively infrequently. However, given oracles frequently handle a high volume of transactions they must connect their private key to automation. This means a hotkey is hosted on the server or cloud environment where the oracle’s virtual machine runs. If the server is hacked, the oracle hotkey can be used to sign exploitative results on-chain.
The Oracle Operator Risk
Furthermore, the oracle itself may act maliciously and manipulate the data provided to the smart contract e.g. the oracle operator enters the lottery themself and makes themself the winner.
Therefore, the question now is how to prevent the oracle hotkey problem and operator risk and how to select a reliable and trustable blockchain oracle.
Main Mechanisms for Trustworthy Oracles
Data from Source:
Data providers pushing data directly on-chain lacks scalability as the low likelihood of writing to the chain for native companies, and it doesn't address oracle hotkey and operator risks either.
Multiple Validators:
While a decentralized oracle network (DON) use multiple oracle nodes independently verify information and request, and post the final results on-chain, they don't eliminate collaboration risks and may still fall prey to hacking.
Hardware secure enclaves:
Intel SGX technology provides the solution to the oracle hotkey and operator risks by enabling the creation of encrypted regions of memory, called enclaves, using secret keys embedded in the hardware. When enclaves are created, the CPU prevents any non-enclave access to the memory region regardless of privilege level. As such, data can be sent to the enclave and oracle private keys stored there with the guarantee they will be inaccessible to the host system.
See Applied Blockchain White Paper for more details about this confidential computing technology.
Silent Data
Silent Data creates privacy-preserving proof regarding data that lies outside the blockchain by leveraging Intel SGX technology, thus closing the gap in the oracle market re-handling private data.
All private oracle keys and user's data is locked and processed within the hardware secure enclave without revealing before posting data on-chain, and is not actually accessed and readable by Silent Data servers, even if the servers were to be hacked.
Want to know how all this is possible? Check out intro to Silent Data and the use case Stripe webhooks posting data to the chain.
Conclusion
Blockchain oracles connect the on-chain world with the real world, and their development not only strengthens the foundation of Web3 but also provides more opportunities for sensitive sectors. However, understanding how oracles verify data provided on-chain is very important for developers to be able to select the correct oracle for their use case.
