iExec Trusted Decentralized Oracle Demo for Beginners
By: Hadrien Croubois
Tags: Blockchain, Bitcoin, Oracles, Devletters, Ethereum

The iExec onboarding demo for blockchain developers offers a sandbox test environment, providing a comparison between standard decentralized oracles and iExec Trusted Decentralized Oracles. The demo illustrates how a Decentralized Oracle with an extra security layer added, Trusted Execution Environments (TEE), is essential for any app that relies on external data sources.

➡️ Play with the sandbox: Test decentralized oracles in 2 minutes:

Decentralized Oracles with iExec

It has long been possible to build decentralized applications with iExec, but what about the real-world data that these applications use? The iExec technical stack allows you to integrate decentralized oracles into your Web3 dapps to retrieve real-world data from traditional ‘web2’ sources. But how can we be sure that this data comes from a trusted source? The answer is the iExec Decentralized Oracle with TEE

The iExec Decentralized Oracle with Trusted Execution Environments (TEE).

The iExec Decentralized Oracle works by carrying out computation on data ‘off-chain’, before returning certified results to the blockchain. This certification is achieved using an on-chain consensus (iExec’s PoCo consensus protocol). The added Trusted Execution Environments (TEE) works by processing results in a highly secured environment (Intel® SGX hardware enclaves), meaning no one can access or change them.

Test iExec Trusted Decentralized Oracles with the new sandbox:

To understand the differences between a standard decentralized oracle and an iExec Decentralized Oracle with TEE using reliable and verified data sources, the new iExec demo uses the analogy of soldiers on a battlefield. You can play the role of the enemy force, trying to send false information and see how the smart contract reacts.

➡️ Play with the sandbox: Test decentralized oracles in 2 minutes:

Technical Explanation: iExec Decentralized Oracles

There are two essential aspects that differentiate iExec Trusted Decentralized Oracles from other oracles solutions: requester decentralization and data certification.

In most existing oracle solutions, a few trusted accounts have the ability to publish data on-chain. This data is either published as such or combined with data from other providers to produce a median value. Still, relying on this type of oracle means that updates can only be triggered by a few parties. In case an update is needed, these parties might be slow to react.

Requester decentralization makes the iExec decentralized oracle solution different. iExec decentralized oracles are designed so that anyone can request an update. This means that, as a user, if you believe some value as a change in such a way that needs to be reflected on-chain (for example a price change) you have the ability to trigger an iExec execution that will retrieve and certify the new value so that on-chain oracle register the update.

Of course, the update you request must follow a specific set of rules to be valid. These rules are defined by the receiving oracle itself. Configuration of the oracle is therefore essential to its security.

In order to trigger an oracle update, the requester produces and signs a request order. This structure contains the details of the execution, including the application, the parameters, and the callback address. This order is then matched with compatible orders representing the other parties involved in the execution (application, workerpool, …). This initiates an iExec execution that is certified by the ‘PoCo’ consensus protocol, and according to the security guarantees required by the ‘request order’.

Once the execution is complete, and if the requester included the oracle address in the “callback” field of the requester order, the iExec smart contracts will automatically call the oracle contract to notify it of the availability of the result. The oracle contract has the ability to check the parameters of the corresponding iExec task to verify the quality of the data. In particular, the oracle is able to verify that the data has been produced by a specific, trusted, application and that this application did indeed run in a TEE enclave.

The oracle configuration allows it to remain decentralized (anyone can trigger an update) while being secured (the execution corresponds to an audited application that ran in a secured enclave). Tooling to easily build an iExec oracle, including the result verification mechanism, is available in the iExecDoracle contract (available on npm through the @iexec/doracle package).

The sandbox link to this article presents two oracles that actually use the same source code, but with a different configuration:

The basic oracle, which no restriction, that accepts invalid updates for malicious application: 0x595977Ed20F93a75e3BB4497b23833591A22897a

The secure oracle, that only accepts updates for a trusted application, and which requires the update to have the TEE flag enabled: 0x06f0825cF7AF1DD0986eF40C273a51f1a032C8Dd

The activity of these oracles, including accepted and refused updates, is indexed by this subgraph.

Test iExec Decentralized Oracles for yourself with the new sandbox:

To understand the differences between a standard decentralized oracle and an iExec Decentralized Oracle with TEE that uses reliable and verified data, the new iExec demo uses the analogy of soldiers on a battlefield. You can play the role of the enemy force, trying to send false information and see how the smart contract reacts.

➡️ Play with the sandbox: Test decentralized oracles in 2 minutes: