I don’t know about you, but when I hear the word “Oracle,” my mind automatically thinks of the Oracle of Delphi. As historicmysteries.com describes the Oracle of Delphi, “The Oracle of Delphi was an important Greek priestess and soothsayer who practiced divination in the Temple of Apollo at the ancient sanctuary of Delphi on Mount Parnassus. Also known as the Pythia, the oracle was a real woman carefully selected by the priests of the sanctuary. When one Pythia died, another one took her place as the high priestess.”
From Greece and beyond, folks would come to have their questions and concerns about the future answered by the Pythia, the priestess of Apollo. The Oracle’s answers, generally cryptic, could decide something as minor as when a farmer would plant his crops, to a significant query as to when an empire should declare war.
In the digital world, the need to *oraclize is growing!
Life, unlike the blockchain, is not linear. Therefore a means to convey information to and from the blockchain for verification is satisfied by the introduction of Oracle technology.
A blockchain oracle marries the offline data to online data needed to create a smart contract. Smart contracts contain the rules, and these “oracles” provide them with the data they need to trigger and carry them out. The use-cases of smart contracts are endless so, the “inbound” Oracles (receiving information to the blockchain for the creation of smart contracts) is, at least theoretically, more significant than “outbound” Oracles.
For example, in real-estate: a property is for sale at a specific price. An inbound Oracle feeds this price to the blockchain (along with other pertinent information about the property), creating a smart contract. When a buyer meets the obligation, the smart contract is fulfilled. The Oracle verifies the completeness of the contract and executes the release of the funds. The Oracle could even serve as a signatory in a multi-sig deal.
*a term coined by Provable – an online Oracle service.
Types of Oracles on the blockchain:
Oracles give a means for smart contracts to communicate outside of a decentralized blockchain network. Blockchain oracles can assume various forms. Some of them include but are certainly not limited to:
- Software oracles
- Hardware oracles
- Inbound oracles
- Outbound oracles
- Consensus-based oracles
Software oracles – This type of Oracle generally includes a variety of online sources of information that are easily accessible on websites and public databases. Example: data such as temperatures, weather predictions, public transport information, and the current market prices of various financial assets. Software oracles allow for the collection of the most up-to-date data to smart contracts.
Hardware oracles – To assist in tracking of merchandise which has an RFID tag, this type of Oracle can send information of any change occurrence from the real world to the smart contract. In essence, hardware oracles can facilitate the tracking of goods along the supply chains.
Inbound oracles – This type of oracle functions simply and solely to supply data to smart contracts. The provided data is external to the smart contract and, upon receiving information, begins a path of execution. (The weather website providing air temperature readings as exampled above would be an inbound oracle.)
Outbound oracles – These oracles communicate smart contract data to an external source. As an example, once a person has been identified as the victor of the wager, the smart contract can communicates this information to the wallet provider in order to automatically update their wallet balance to show an increase in funds. In this instance, the smart contract itself is operates as an outbound oracle.
Consensus-based oracles – The function of this oracle type is to query multiple oracle sources, then, based on the consensus, arrive at an outcome. For example, instead of using just one website as its source as in the previous case, a total of four sites and databases could be used. If all the oracles return the same temperature reading, the smart contract can execute.
Oracles Require Trust
Even with the advantages of oracles, there is one disadvantage:
Oracles require trust – The sources from where data is collected must be credible to be of value to use in a smart contract. Using the previous example, if someone somehow gained access to the weather website, it would then be easy to return a temperature reading that would allow for them to win the wager and hence win fulfillment of the smart contract. In short, if the data being supplied to smart contracts by oracles prove to be faulty, there exist security concerns as to the validity of the executing smart contract.
The possible remedy for this issue is to gather data from multiple Oracles rather than just one. Say the oracle returned a reading of 24 °C, but four other Oracles reported a value of 18 °C. In this case, more conditions could be added to the programming to resolve the conflict. The smart contract could be programmed to accept only the majority reported value, in this case, 18 °C, which would be the deciding factor in fulfilling the contract. Then again, the smart contract could be programmed no to execute at all and would require the intervention of both parties in the smart contract.
At this time, Oracles are needed as a means of communicating data from third-parties to smart contracts. They increase the scope of what a blockchain protocol can do by facilitating critical data exchanged to smart contracts in the network, both inbound as well as outbound.
The trust factor that Oracles require fly in the face of the trustless, decentralized nature of the blockchain-based protocols. To mitigate the lack of trust, smart contracts cast an increased level of complexity by adding multiple oracles for adding critical data to the smart contract.