If a smart contract requires data from the external world (for instance, an insurance contract requiring the level of flood waters to determine payouts), the contract cannot directly query sources to pull dynamic or volatile data. If each copy of a smart contract running on different nodes were to directly query such sources, those different queries would very likely return different data (even if sent to the same source). Consequently, each smart contract copy would process different data and create different results — destroying the fundamental consistency of the smart contract state.
To guarantee that multiple instances of the state controlled by a smart contract do not diverge, smart contracts can only act on data that exists on the ledger — and has been processed into consensus state.
One possibility would be to allow clients to submit such data themselves, after retrieving from external sources. But a client of a smart contract might be motivated to lie about the value in order to gain some benefit.
Oracles provide a set of mechanisms that collectively ensure that the necessary data exists on the ledger such that smart contracts can avail themselves of it and be confident of its credibility. An oracle is a service that provides data to a smart contract deployed on a ledger, via transactions submitted to the ledger and applied to consensus state.
Oracles listen for requests coming from the ledger for the particular data they provide, obtain that data, and then return it back to the ledger in the form of a transaction for the requesting application to use. For instance, if a smart contract required the temperature of a shipping container at a given time (to ensure that the frozen food within did not thaw), an oracle would query the relevant sensor on the container and push those readings back to the supply chain contract through a transaction submitted to that contract.
Oracles typically manifest as:
1. A smart contract, to which requests for the associated data can be sent, with the request stipulating a callback address to which the response transaction should be sent.
2. Infrastructure by which the data can be sourced (for example: making API calls, querying a set of users on some subjective proposition).
3. Mechanisms to submit the response as a transaction.
While an oracle could connect to a single data source, the desire for decentralization generally suggests incorporating multiple sources through an oracle network. For instance, if a smart contract requires the temperature not of a single shipping container, but of a city on a given day, multiple weather networks might be queried through their various APIs, with an average or median calculated on the different numbers. In this way, the effect of any single weather feed being corrupt or compromised can be mitigated.
The high level architecture for an oracle is represented below:
The dapp smart contract requires some data from the external world; the oracle smart contract and supporting off-ledger infrastructure work together in order to obtain and deliver that data to the dapp contract.
The above description of oracles is generic — we can consider how oracles will manifest on the Hedera platform and whether there are any special considerations or advantages.
As the Hedera ledger supports the Solidity language, any oracle smart contract components (Step 1 in the above) will work on Hedera as they do on Ethereum. Additionally, the sourcing of data from various data origins (Step 3 in the above) will be unchanged. Steps 2 and 4 in the above will however need to be bound to the Hedera platform– leveraging Hedera’s comparable mechanisms. For instance, Step 3 could leverage Hedera’s records and state proofs or perhaps the network of mirror nodes, and Step 4 would manifest as a Hedera API ContractCall.
While designed to minimize the risk, oracles inevitably introduce the possibility of corrupt data compromising the integrity of a smart contract’s state. The Hedera network uniquely offers an optional binding arbitration model which provides a mechanism to remediate. If, when the smart contract was first initialized on the Hedera platform, particular public keys were designated with multi-sig logic, then the corresponding private keys would have administrative rights over that contract. If, in the future, it was determined that an oracle had sent incorrect or corrupted data to the contract, then those admin keys could, after suitable analysis and an arbitration process, remediate the situation.
In Ethereum, the transaction by which the oracle submits the data back to the smart contract, like any other transaction, must be funded with sufficient gas and a gas price to encourage miners to add that transaction to their blocks. If the stipulated gas price is insufficient, then miners may not choose to add that transaction, and the transaction will wait in the mempool and consequently be unavailable to the waiting smart contract. There is nothing comparable to ‘gas price’ in Hedera’s fee model — clients do not need to encourage/bribe nodes to process a given transaction as the hashgraph algorithm is leaderless and does not empower any one node with special powers.
Additionally, the expected consensus latency for Hedera transactions is seconds and not minutes or hours. Consequently, after initiating a request of an oracle for some data, a smart contract can expect to quickly have access to the returned data (depending, of course, on the latency of the oracle network itself).
Hedera’s support for consensus timestamps and state proofs could further help resolve disagreements over oracle data. Imagine the following sequence:
1. The oracle receives a smart contract request for shipping container geolocation and temperature.
2. The oracle retrieves geolocation and temperature data from the relevant container.
3. The oracle submits geolocation and temperature data to the relevant smart contract via a transaction to Hedera. The transaction stipulates that a record for the transaction be created.
4. The shipping smart contract processes the data.
5. Within an hour, the oracle queries the Hedera network for the transaction record and stipulates it desires a state proof be created.
6. Hedera node returns transaction record and state proof that indicates:
7. The oracle stores away the above information in case of future litigation where the validity of the geolocation, temperature data, and timing of its submission to the Hedera ledger is questioned.
If smart contracts are to model real-world business processes and interactions, they must be connected to that world. Oracles — whether software, hardware, or human — enable that connection. Hedera provides a number of features that uniquely enables smart contract oracles.