Blockchain oracles are the services that provide smart contracts with external information, which serve as bridges between blockchain and the outside world. Oracles are a powerful tool that can provide interoperability between different blockchains and communicate with external data sources.
Blockchain oracles provide a link between off-chain and on-chain data where oracles are vital within the blockchain ecosystem because they broaden the scope in which smart contracts can operate.
We can say that a blockchain oracle is not the data source itself, but 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.
In this article, we will discuss the types of blockchain oracles, use-cases, and many more!
Why do we need Blockchain Oracles?
Smart contracts have been designed to execute irreversible operations. The information fed into the contract must come from a relatively trusted source. This is why, when data is coming from an external source, it can be a bit of a dilemma. However, on the flip side, it does increase the number of use-cases exponentially.
Oracle signs claim about the state of the world and upload it to the blockchain. Blockchains seem to live in their isolated reality, completely cut off from the rest of the world. An oracle can connect the blockchain to the real world by providing it with relevant information. The information may be retrieved or aggregated from one or multiple trusted sources by one or multiple oracles.
Different types of Blockchain Oracles
There are different types of oracles:
- Software oracles: Software oracles interact with online sources of information and transmit it to the blockchain. This information can come from online databases, servers, and websites – essentially, any data source on the Web. 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.
- Hardware oracles: 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.
- Inbound and outbound oracles: Inbound oracles transmit information from external sources to smart contracts, while outbound oracles send information from smart contracts to the external world.
- Centralized and decentralized oracles: 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. On the other hand, 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.
- Contract-specific oracles: Contract-specific oracle is designed to be used by a single smart contract, as 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.
- Human oracles: Sometimes individuals with specialized knowledge in a particular field can also serve as oracles. They can research and verify the authenticity of the 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.
- Prediction market: Decentralized prediction markets like Augur and Gnosis leverage the “knowledge of the crowd” to predict the future state of the markets. These markets must capture knowledge via multiple oracles or off-chain event settlements.
- DeFi: The combination of smart contracts and finance has ushered in the era of Decentralized Finance (DeFi). These products need access to trustless data feeds, which could be provided by oracles.
- Insurance: It could be possible to buy insurance products over the blockchain via oracles. Since the biggest issue in insurance is a fraud, the decentralization of the blockchain and the reliability of oracles are a perfect combo to resolve this issue.
- Shipment: Oracles can replace the existing, centralized GPS systems to provide reliable location mapping for dApps to track shipments.
The Problem with Blockchain
Since the blockchain has its distributed ledger nature, each node in the network has to be able to find the same end result given the same input. Otherwise, when a node looks to validate a transaction another node makes, it would end up with a different result. This architecture is intentional, and it’s designed to be deterministic intentionally.
Using one blockchain oracle is a huge risk and Chainlink offers a fantastic new ecosystem around data. Blockchain oracles are the key to unlocking the future that smart contracts have for us. Oracles also provide a way for blockchain to see into each other. This is known as interoperability and is an important next step as well.
The main challenge with oracles is that people need to trust these outside sources of information, whether they come from a website or a sensor. Since oracles are third-party services that are not part of the blockchain consensus mechanism, they are not subject to the underlying security mechanisms that this public infrastructure provides. One could replicate “man-in-the-middle attacks” standing between contracts and oracles.
The robustness assurance of this “second layer” is of utmost importance. Different trusted computing techniques can be used as a way of solving these issues. However, this topic will need more attention, as secure oracles are a bottleneck for smart contract security. If oracle security is not adequately provided, it will be a show stopper for widespread smart contract implementation.
A reliable mechanism that facilitates communication between smart contracts and the external world is vital to the global adoption of blockchain.
How to maintain Blockchain Oracle’s reliability?
There are four techniques that oracles can use to maintain its reliability:
- Multiple data sources: If your oracle is collecting information from multiple data sources, the probability of it receiving wrong information is low. However, the oracle itself can act as a point-of-failure.
- Multiple oracles: Another approach is to use multiple oracles to collect information that negates the “single-point-of-failure” problem. However, the risk here is that there is a chance a majority of these oracles may have compromised sources of information.
- Incentive mechanism: Oracles can take a page out of Casper protocol and include a “stake-slashing” mechanism to ensure that the actors involved are incentivized to act honestly. The key here is to incorporate a form of tokenomics that forces the nodes in the oracle network to perform honest work and behave well. If they perform well, they get a reward, if not, then they can be punished via a slashing mechanism.
- Trusted execution environment (TEEs): TEEs allows an application to be executed in a secluded environment called an “enclave” that provides it with hardware protection.
Decentralized oracles have the potential to introduce safeguard mechanisms that could eliminate a lot of systemic risk from the blockchain ecosystem, as 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.
Thus, without blockchain oracles, smart contracts would have to rely only on information already within their networks, which would considerably limit their capabilities.