Example
Example of the Solidity contract using ODF oracle:Getting Started
Start by installing@opendatafabric/contracts package that contains oracle interface and request/response types.
Supported Networks
| Network | Contract Address | Oracle Fee |
|---|---|---|
| Ethereum Sepolia Testnet | 0xf1960569d1b4a23c34109d9341af6496ed90c0c3 | 0 |
| BNB Smart Chain Testnet | 0x83857865971e941933dd36ebbf9475a867f67ca6 | 0 |
| Ethereum Mainnet | coming soon | 0 |
| Optimism | coming soon | 0 |
Verifiability
Every response submitted to the oracle by data providers includes special data that allows the query to be reproduced later against the same exact version of input data. In REST API semantics an oracle request that looks like this:input.datasets block of the response contains state information that associates every input dataset with the hash of the last block that was considered during the query.
Whenever a provider supplies a response - this state information is recorded in the events emitted by the oracle contract on the blockchain.
This data acts as a commitment using which a data consumer can dispute results of a query. If another party repeats the same computations using the state data and arrives at different result - this means that the original provider has acted maliciously. See commitments documentation for details.
The reproducibility and verifiability of queries therefore make ODF the first of a kind optimistic oracle where:
- Queries can be fulfilled fast and cheap just by one provider
- Without going through a complex consensus mechanism
- While validity of data can still be ensured through the dispute resolution and sampling mechanisms along with staking and slashing.
Commitment Properties
Using the criteria discussed in the commitments documentation the oracle commitment can be described as follows:- Hiding - NO
- The entire request and response data is publicly available, but this as an inherent limitation of non-ZK blockchains
- Binding - YES
- All inputs and outputs are immutably stored on-chain
- Succinct - YES*
- All response data ends up stored which we cannot avoid, but the commitment itself does not add much overhead
- Deterministic - YES
- Reproducible - YES
- Original query with all of its parameters is stored on-chain and can be repeated against the state information in response
- Non-repudiable - YES
- Automatically achieved as the provider signs the response transaction with its private key
- Composable - YES
- Through recursive nature of the commitment
Troubleshooting
To better understand what oracle providers return find the incoming oracle transaction in the block explorer e.g. 0x0f3a..4ff6. Find theProvideResults log:
Copy the data field and paste it in https://cbor.me/ to get something like this:
The first three fields are: version, success, data. Refer to OdfResponse to understand the layout of the other fields.
Once you have one oracle response - you can use it as input in your unit tests to fully debug the decoding and processing logic without constantly re-deploying the contract and spending a lot of gas.
Here’s an example of one such tests in foundry: