Check out the Issue Explorer
Looking to fund some work? You can submit a new Funded Issue here.
### What you will learn
- Feed API data into your Ethereum smart contract using a decentralized oracle.
- You must know at least one programming language
- Basic knowledge of how Ethereum and smart contracts work
### App requirements
- **Use case**: soccer game betting platforms
- **Data source**: soccer game API (example)
- **Input**: a soccer game ID
- **Output**: official final score
### What I need to do?
An iExec DOracle needs two parts: Off-chain **dockerized applicatio**n, and on-chain **smart contract**.
**1. Dockerized application (off-chain)**
You need to write a logic that does the following steps:
- Fetch the data from the API
- store the hash of the result in the _determinism.iexec_ file
- store the encoded result (using ABI.encode) in the _callback.iexec_ file
Then, push you docker image on Dockerhub, and deploy it on iExec using the SDK.
**2. Smart contract (on-chain)**
- Edit the [provided template](https://github.com/iExecBlockchainComputing/price-feed-doracle/blob/master/contracts/PriceOracle.sol) by filling your app ID
- Use truffle to deploy the smart contract
### Going further: About Decentralized Oracles (optional read)
Programmable blockchains and smart contracts are a big deal, but they live in siloed environments and as such have very limited access to the outside world (i.e. the Internet). The iExec V3 makes it trivial for anyone to deploy his own decentralized oracle, hence allowing developers to leverage the terabytes of data available on the Web 2.0 to build a whole new range of useful and impactful dapps without compromising on the security.
The iExec DOracle uses iExec to execute the oracle logic off-chain and return certified results to the blockchain. Certification can be achieved using a combination of hardware security (TEE - Trusted Execution Environment) and on-chain consensus (iExec’s PoCo). These two mechanism provides tools to ensure results of a DOracle execution can be trusted for the on-chain settlement of off-chain events.
Documentation of the iExec platform, including details about de PoCo protocol can be found at [https://docs.iex.ec](https://docs.iex.ec).
### Components of an iExec DOracle.
In order to run, an iExec DOracle needs three essential components:
1. A dockerized application = off-chain logic that fetches the data your dapp needs.
2. The output = The data your on-chain dapp needs.
3. A receiving smart contract = The smart contract that will consume the output.
### The app & the output
The dockerized oracle app contains the logic that will be executed and verified by the iExec platform when a call is requested. This logic can be implemented in any language and access any data as long as it can be dockerized and it follows below simple guidelines:
1. Given a set of input parameters, multiple execution of the same app must provide the exact same results (we say it is a deterministic application).
2. Output must be encoded in a way that makes it readable on the blockchain. Consider using the abi.encode format.
3. The result fetched by the appEncoded results (bytes) must be written to the /iexec_out/callback.iexec file. Additionnaly the keccak256 hash of the results (bytes32) must be written to the /iexec_out/determinism.iexec file.
The iExec middleware will perform the consensus on the determinism.iexec file, and will store the callback.iexec file on Ethereum.
### The receiving smart contract
The receiving smart contract will be the on-chain receiver that will consume the output. This contract can contain any logic, but it should inherit from the IexecDoracle (available on Github) which provides a routine to retrieve and verify the result of an oracle execution. The PriceOracle shows a good example of such contract.
### Security considerations
The iExec framework proposes all the tools to build a secure decentralized oracle. However, simply using the iExec framework won’t prevent issues in the oracle design from threatening the security and the decentralization of the oracle. Here are some points that should be considered:
External resources (such as Web 2.0 APIs) are centralized point of failure. DOracles can forward data from such APIs to the blockchain in a trustless manner, but the data reported on-chain is still subject to manipulation by the API administrator.
If trying to report random values from an off-chain source to the blockchain, be aware that the requester of the call might be able to control the seed. You may want to use additional proof of origin or use commit reveal pattern that only accept oracle calls for which the request has been registered on-chain before the actual value was predictable. In general, providing cryptographically secure randomness to a blockchain is difficult, so don’t try it unless you really understand the different attack vectors.
Design your receiver smart contract to be trustless and censorship resistant. If only a single actor can update it then your oracle might not be properly designed. Anyone with an interest on updating a value must be able to pay for an oracle call that will provided an updated value to the blockchain which nobody can argue against.
### Need help?
Again, the documentation is here: [https://docs.iex.ec](https://docs.iex.ec).
Feel free to ask for more information on our [Slack](https://slack.iex.ec/).