By Jinghui Liao, Core Developer, Neo
Introduction
This article presents a project that has devised a novel solution to a recurrent issue in blockchain technology. Researchers and engineers from Wayne State University, Neo Global Development, Southern University of Science and Technology, Purdue University, Hong Kong Polytechnic University, University of Hong Kong, and University of Delaware are collaborating on this project.
The blockchain dilemma
When it comes to blockchain development, delivery is a key constraint. In other words: How can we apply blockchain technology in real-life scenarios? To achieve this goal, we make constant assumptions about the applications of this technology in areas such as gaming, invoicing, and non-fungible tokens. But such use cases only scratch the surface of the full capabilities of blockchain. We could compare the state of use cases for blockchain today to the current adoption level of 5G technology, which is rich with features and functions but in reality mostly gets used simply for speed tests.
If scenarios such as gaming aren’t suitable for blockchain technology, it’s reasonable to ask where we can find more suitable scenarios. However, there is a challenge: Blockchain technology is an isolated system. For safety and security, the blockchain only trusts its own on-chain data. It does not accept data flowing from outside of its native blockchain environment. For instance, unspent transaction output (UTXO) is constructed from on-chain transactions. As another example, when a smart contract is executed, it can only access on-chain data through a few interfaces.
As a result, if users want to work with blockchain technology, they cannot rely on off-chain information, despite the fact that such interactions are required in most real-world scenarios. This limitation is out of sync with the requirements of many every-day use cases that could otherwise be a fit for blockchain technology. As just a few examples:
- The applications that people use on their cell phones require an internet connection.
- Ticket-booking apps need real-time information about the remaining numbers and prices of tickets.
- Trading apps need access to pricing information.
- Delivery apps need access to the latest logistics information.
Bottom line: For some time, there was no way to use blockchain to accomplish such tasks.
In response to the need to broaden the application scenarios of blockchain and access its full potential, an interaction method was born: Oracle, which can feed the off-chain data flow to the blockchain.
The beauty of the oracle
A blockchain oracle is a trusted third party that engages between the traditional internet and the blockchain. The smart contract on blockchain must trust both the data provided by oracles and the oracle’s authenticity (trusting that it is free of data falsification or tampering). To provide this trust to the blockchain, the oracle system must ensure the safety and security of its own system. For example, Chainlink, a well-known oracle, uses distributed nodes to aggregate the data to ensure its authenticity. As another example, Universal Market Access (UMA) adopts the dispute resolution mechanism to uncover problematic data.
An oracle is a strong fortress of trust outside of the native blockchain environment. This fortress of trust can provide almost any type of off-chain data for blockchain. This capability greatly broadens the application scenarios for blockchain and unveils a bright future for blockchain technology. It is no exaggeration to say that the oracle is the second great revolution of blockchain after smart contracts.
Oracle’s fatal flaw
Clearly, it is good news that using an oracle solves a structural issue that was a critical impediment to the future of blockchain, and the availability of oracles has boosted blockchain development. But unfortunately, the current oracle system also has a fatal flaw: Latency.
Running an oracle system can be accomplished in either of two main ways:
- As one option, a request can be triggered by a smart contract, after which the oracle can access the off-chain data according to the request. Then the oracle returns the data to the smart contract.
- Or the oracle can continuously synchronize data on-chain. As long as the change of data outside the blockchain environment exceeds the threshold, a transaction will be triggered to update the data on-chain to ensure that users can use the most accurate data.
But both types of oracles have a core flaw: The time-consuming process of obtaining data through consensus. Figure 3 provides an example of this issue: The user first sends a transaction to the blockchain network. After a round of consensus (e.g. 15 seconds), the corresponding smart contract throws out a data request. Then the oracle captures the request (taking approximately 100 milliseconds). After capturing the request, the oracle sends data requests to the source outside the blockchain environment. Next, the feedback will be sent to the blockchain network in the form of a transaction (taking approximately another 100 milliseconds).
In this example, we can see that there is at least a latency of 15 seconds + 100 milliseconds + 100 milliseconds between when the user initiates the transaction and when the final data source returns the data. This latency may seem small. But in the case of a black swan event or a hacker attack, a latency of ten seconds or more would be fatal.
We need look no further than the attack that happened on the BNB chain this month to see the havoc that this kind of latency can wreak: Hackers took advantage of the oracle’s price latency and stole $15 million in equivalent tokens.(For more about this recent attack, read How Attackers Made $15M From Staking Platform Helio After Ankr Exploit).
A solution: A zero-latency oracle
Over the past year, our project research team has grown increasingly concerned about the serious latency problem in the existing oracle system. This issue has become even more concerning in 2022 in light of the LUNA event and the FTX bankruptcy. In the LUNA event, the price of LUNA fluctuated up to 50% within a minute at its peak, and the price of FTX fluctuated up to 20% within a minute. Highly volatile prices could not be synchronized to the chain in a timely way by traditional oracle systems. Based on such concerning issues in the blockchain world, we strongly believe that having an oracle system that can map 100% of off-chain pricing data to the blockchain is a must.
Fortunately, the problem of latency in oracles is not insurmountable.
The traditional solution to latency would be for users to send the data request directly to the oracle without going through the blockchain. Traditional oracle systems (regardless of their structures) invariably isolate themselves from the user, who interacts first with the blockchain. Next, the blockchain interacts with the oracle.
There are two rationales for using this traditional method:
- First, this method makes it relatively easy for the user to interact directly with the blockchain, fully reusing all existing wallet systems. The user does not need to know how the contract triggers data requests or how to access the data.
- Second, this structure avoids gas fees. With this method, a user would pay the gas fee first, and then the oracle would provide the service. (If a user interacts with the oracle directly, the resulting gas fees charged would be a problem.)
However, this traditional approach has its own problems:
- The oracle would initially provide the service before getting a gas fee reimbursement from the user. If this strategy is handled improperly, it will raise the risk of a denial of service attack. For example, if the oracle requests the data and constructs an oracle transaction for an attacker, then the execution of the oracle transaction is reverted, resulting in the oracle paying the oracle transaction fee but being unable to receive reimbursement from the attacker, consequently depleting the gas of oracle nodes.
- Also, it is hard to package together the data requested by the user with the data obtained by the oracle. We cannot simply splice the two data sets together: The oracle, as a third-party data provider, must provide data with verifiability, and the contract on chain must be verifiable. A smart contract on the blockchain must be able to verify that the data it gets is indeed requested by the user, verify that the request is indeed initiated by a user, and verify that the request has not been reused.
Our research team has found a solution to address these issues by enabling a zero-latency oracle, as shown in Figure 4.
This solution will make it possible to implement the structure of direct user interaction with the oracle in a secure way.
To this end, our research team’s work is focused on the following:
- Adopt a trusted execution environment (TEE) to enhance the security of the oracle nodes. A TEE is in an isolated execution environment. This means that even if attackers break the operating system of oracle nodes, they cannot break the core logic protected by the TEE or tamper with the data requested by the TLS link initiated by the TEE.
- Use a committee mechanism to defend a single point of failure (SPOF). Although the TEE provides strong security to ensure that its execution logic and internal data are not tampered with, TEE still has to operate on a physical device. This means that an attacker could implement a physical DOS attack on the oracle node. Extreme attackers may even use side channel attacks to compromise the TEE for long periods of time.Thus, we are using a committee mechanism that uses multiple TEEs to jointly process user data requests. To ensure the security of the whole Oracle system, the committee TEE nodes can be from different organizations (or even from different TEE implementations).
- Use structural hashing to package user requests with data. To guarantee the verifiability of user data requests and data packaged by the oracle, we refer to the structural hash and signature protocol proposed by EIP712 to construct the structure of user data requests and oracle transactions used to submit data.
What’s next for the project
This oracle project has gone through several months of research, design, implementation, and testing, and we have developed a system prototype. We have tested our oracle system with more than 200 pricing data points. Based on this testing, we have confirmed that the system can provide users with “what you see is what you get” (WYSIWYG) off-chain data calls with a 100 ms latency, achieving a close-to-zero-error state for all data streams.
The related paper has been completed, and the related patent application is pending.
Our research team looks forward to the next steps in opening a secure pathway to a new level of real-world use cases in the world of blockchain technology.
Learn more
A previous article by this author on the Oracle system is available here: Oracle Machine.
Copyright © 2022, All rights reserved
