Community Submission - Author: Vallery Mou
Blockchains and smart contracts cannot access off-chain data (data that is outside of the network). However, for many contractual agreements, it is vital to have relevant information from the outside world to execute the agreement.
This is where blockchain oracles come into play, as they provide a link between off-chain and on-chain data. Oracles are vital within the blockchain ecosystem because they broaden the scope in which smart contracts can operate. Without blockchain oracles, smart contracts would have very limited use as they would only have access to data from within their networks.
It’s important to note that a blockchain oracle is not the data source itself, but rather the layer that queries, verifies, and authenticates external data sources and then relays that information. The data transmitted by oracles comes in many forms – price information, the successful completion of a payment, or the temperature measured by a sensor.
To call data from the outside world, the smart contract has to be invoked, and network resources have to be spent. Some oracles also have the ability to not only relay information to smart contracts but to send it back to external sources.
Many different types of oracles exist – how a blockchain oracle operates is entirely dependent on what it is designed for. This article will go through some of those designs.
Suppose that Alice and Bob place a bet on who the winner of the US presidential election will be. Alice believes that the Republican candidate will win, while Bob believes that the Democrat will be the winner. They agree on the terms of the bet and lock their funds in a smart contract, which will release all the funds to the winner based on the results of the election.
Since the smart contract cannot interact with external data, it has to depend on an oracle to feed it the necessary information – in this case, the results of the presidential election. After the election is over, the oracle queries a trusted API to find out which candidate has won and relays this information to the smart contract. The contract then sends the funds to Alice or Bob, depending on the outcome.
Without the oracle relaying the data, there would have been no way to settle this bet in a way that couldn’t be gamed by one of the participants.
Blockchain oracles can be classified depending on a number of different qualities:
A single oracle can fall into multiple categories. For example, an oracle that sources information from a company website is a centralized inbound software oracle.
Software oracles interact with online sources of information and transmit it to the blockchain. This information can come from online databases, servers, websites – essentially, any data source on the Web.
The fact that software oracles are connected to the Internet not only allows them to supply information to smart contracts but also to transmit that information in real-time. This makes them one of the most common types of blockchain oracles.
Information typically provided by software oracles can include exchange rates, digital asset prices, or real-time flight information.
Some smart contracts need to interface with the real world. Hardware oracles are designed to get information from the physical world and make it available to smart contracts. Such information could be relayed from electronic sensors, barcode scanners, and other information reading devices.
A hardware oracle essentially “translates” real-world events into digital values that can be understood by smart contracts.
An example of this could be a sensor that checks if a truck transporting goods has arrived at a loading bay. If it does, it relays the information to a smart contract that can then execute decisions based on it.
If you’d like to read more on a similar subject, check out Blockchain Use Cases: Supply Chain.
Inbound oracles transmit information from external sources to smart contracts, while outbound oracles send information from smart contracts to the external world.
An example of an inbound oracle is one that tells a smart contract what the temperature is measured by a sensor. An example of an outbound oracle can be considered with a smart lock. If funds are deposited to an address, the smart contract sends this information through an outbound oracle to a mechanism that unlocks the smart lock.
A centralized oracle is controlled by a single entity and is the sole provider of information for the smart contract. Using only one source of information can be risky – the effectiveness of the contract depends entirely on the entity controlling the oracle. Also, any malicious interference from a bad actor will have a direct impact on the smart contract. The main problem with centralized oracles is the existence of a single point of failure, which makes the contracts less resilient to vulnerabilities and attacks.
Decentralized oracles share some of the same objectives as public blockchains – avoiding counterparty risk. They increase the reliability of the information provided to smart contracts by not relying on a single source of truth. The smart contract queries multiple oracles to determine the validity and accuracy of the data – this is why decentralized oracles can also be referred to as consensus oracles.
Some blockchain projects provide decentralized oracle services to other blockchains. Decentralized oracles can also be useful in prediction markets, where the validity of a certain outcome can be verified by social consensus.
While decentralized oracles aim to achieve trustlessness, it is important to note that just like trustless blockchain networks, decentralized oracles do not completely eliminate trust, but rather distribute it between many participants.
A contract-specific oracle is one that is designed to be used by a single smart contract. This means that if one wants to deploy several smart contracts, a proportionate number of contract-specific oracles have to be developed.
This type of oracle is considered very time-consuming and expensive to maintain. Companies that want to extract data from a variety of sources may find this approach very impractical. On the other hand, since contract-specific oracles can be designed from scratch to serve a specific use case, developers have high flexibility to tailor them to specific requirements.
Sometimes individuals with specialized knowledge in a particular field can also serve as oracles. They can research and verify the authenticity of information from various sources and translate that information to smart contracts. Since human oracles can verify their identity using cryptography, the possibility of a fraudster faking their identity and providing corrupted data is relatively low.
Since smart contracts execute decisions based on data provided by oracles, they are key to a healthy blockchain ecosystem. The main challenge with designing oracles is that if the oracle is compromised, the smart contract relying on it is also compromised. This is often referred to as The Oracle Problem.
Since oracles are not part of the main blockchain consensus, they are unfortunately not part of the security mechanisms that public blockchains can provide. The trust conflict between third-party oracles and the trustless execution of smart contracts remains a mostly unsolved issue.
Man-in-the-middle attacks can also be a threat, where a malicious actor gains access to the data flow between the oracles and the contract and modifies or falsifies the data.
A reliable mechanism that facilitates communication between smart contracts and the external world is vital to the global adoption of blockchains. Without blockchain oracles, smart contracts would have to rely only on information already within their networks, which would considerably limit their capabilities.
Decentralized oracles have the potential to introduce safeguard mechanisms that could eliminate a lot of systemic risk from the blockchain ecosystem. Blockchain oracles remain one of the critical building blocks to be implemented in a secure, reliable, and trustless manner for the blockchain ecosystem to grow.