What are Oracles? Types of Blockchain Oracles
Table of Contents
What is a Blockchain Oracle?
Blockchain oracles are third-party services that supply external data to smart contracts. They act as a connection point between the outside world and blockchains.
Off-chain data is inaccessible to blockchains and smart contracts (data that is outside of the network). However, in order to carry out numerous contractual agreements, it is essential to have pertinent information from the outside world. By acting as a bridge between off-chain and on-chain data, blockchain oracles can be useful in this situation. Oracles are essential components of the blockchain ecosystem since they increase the range of possibilities for smart contracts. Indeed, smart contracts would only be able to access data within its networks if there were no blockchain oracles, which would severely limit their utility.
It's crucial to understand that a blockchain oracle is merely the layer that queries, authenticates, and checks external data sources before relaying that information. The information sent by oracles can take many different forms, such as price details, confirmation of a transaction's success, or sensor-measured temperature data.
The smart contract must be activated and network resources must be used in order to request data from the outside world. Some oracles can also communicate information back to outside sources in addition to relaying it to smart contracts.
There are lots of types of oracles and how it operates is completely dependent on its purpose. In this article, we will go through some of the designs of oracles.
An example of a Blockchain Oracle
Given that David and Thomas wager on who would win in the final of FIFA World Cup 2022 between Argentina and France. David predicts that Argentina will prevail, whereas Thomas believes that France will be the winner. They come to an agreement on the wager’s terms and deposit their money into a smart contract, which will release all of the money to the winner in accordance with the outcome of the football match.
Because the smart contract is unable to interact with external data, it must rely on an oracle to provide it with the essential information, in this case, the results of the final. The winner of the match is determined by the oracle using a trusted API, which it then passes to the smart contract. Depending on the result, the contract subsequently transfers the money to either David or Thomas.
Without the oracle coming into play, there would have been no way to settle this wager in a way that one of the players couldn’t have manipulated the result.
The Blockchain Oracle Problem
Smart contracts are essential to a thriving blockchain ecosystem since they execute decisions based on information provided by oracles. However, the primary problem with oracle design is that any smart contract that depends on oracle is likewise vulnerable. This is referred to as The Oracle Problem.
Blockchains itself cannot make a connection to real-world data (Source)
Blockchains get their most significant qualities, such as strong consensus on the authenticity of user transactions, prevention of double-spending attacks, and mitigation of network downtime, by being purposefully segregated from external systems. Unfortunately, oracles are not a part of the security mechanisms that public blockchains offer because they are not a part of the primary blockchain consensus. The trust problem between smart contracts' trustless execution and third-party oracles is still mostly unresolved.
Man-in-the-middle attacks are another potential danger, in which a malicious actor intercepts the data flow between the contract and the oracles and alters or falsifies it.
The oracle problem must be resolved since the vast majority of smart contract use cases, including DeFi, depend on knowledge of real-world data and off-chain occurrences. Oracles provide a global gateway to off-chain resources, thereby expanding the types of digital agreements that blockchains may support while maintaining the crucial security features of blockchains.
Oracles and smart contracts are beneficial for many major businesses, including asset prices in banking, weather data in insurance, randomness in gaming, identity verification in government, and many more.
How does a Blockchain Oracle work?
Users are entities (smart contracts, for example) that require information from sources other than the blockchain to carry out certain tasks. The user sends a data request to the Oracle contract to begin the fundamental workflow of an Oracle service. Usually, data requests will provide answers to some, all, or none of the following queries:
- What resources may off-chain nodes use to get the needed data?
- How do reporters analyze data from sources to identify relevant data points?
- How many Oracle nodes can take part in the data retrieval?
- How should Oracle report discrepancies be handled?
- What process should be used to filter submissions and combine reports into a single value?
The on-chain element of the Oracle service is the Oracle contract, which receives data requests from other contracts, transmits them to Oracle nodes, and broadcasts the data they receive back to client contracts. In order to generate an aggregate value that it delivers to the requesting contract, this contract may additionally execute various calculations on the returned data points.
When a client contract requests data, the oracle contract exposes a few functions that are called by the client contract. The smart contract will emit a log event containing information about the new request as soon as it is received. This alerts off-chain nodes that have subscribed to the log, and they can then proceed to get the data specified in the log event.
The oracle node is the off-chain portion of the oracle service; it gathers data from other sources, including APIs hosted on third-party servers, and posts it on-chain for smart contracts to use. Oracle nodes carry out the task outlined in the log by listening for events from the on-chain oracle contract and responding to them.
Oracle nodes are frequently used to transmit an HTTP GET request to an API service, parsing the response to extract pertinent data, structuring it into a blockchain-readable output, and sending it on-chain by incorporating it in a transaction to the oracle contract. The oracle node can also be asked to vouch for the accuracy and reliability of submitted data.
Computational oracles also rely on off-chain nodes to carry out computationally complex activities that are impossible to do on-chain due to gas costs and block size restrictions. For instance, the oracle node could be tasked with producing a verifiably random figure (e.g., for blockchain-based games).
Common Oracle Design Patterns
Oracles have several types such as immediate-read, publish-subscribe, and request-response.
The latter two are the most common oracle design patterns among Ethereum contracts, which are outlined below:
A publish-subscribe mechanism-based Oracle service presents a "data feed" that other contracts can frequently access to get information. Client contracts must keep an eye out for updates to the data stored by the oracle since it would change frequently in this situation. A great illustration is an oracle that informs customers of the most recent ETH-USD pricing.
A request-response mechanism-based Oracle allows the client contract to make arbitrary requests for data other than the one provided by a publish-subscribe oracle.
Request-response oracles are ideal in the following circumstances:
- The dataset is too large to fit in a smart contract’s storage
- Users only require a small portion of the data
Request-response oracles are essentially what we discussed in the preceding section, albeit more complicated than publish-subscribe models. An on-chain element of the request-response oracle will take in a data request and send it to an off-chain node for processing.
The cost of obtaining data from an off-chain source must be covered by users that launch data searches. The callback function given in the request requires that the client contract pay the gas expenses incurred by the oracle contract in order to return the result.
Different types of Blockchain Oracles
The classification of Blockchain Oracles are based upon a number of different qualities:
- Source: Does the data originate from software or hardware?
- Direction of information: Is it inbound or outbound?
- Trust: Is it centralized or decentralized?
One oracle may fit into more than one category. For instance, an oracle that draws information from a company website is a centralized inbound software oracle.
Software oracles communicate with internet data sources and send the data to the blockchain. This data can originate from any online database, server, website, or other data source on the Internet.
Software oracles can provide information to smart contracts and send that information in real-time because they are connected to the Internet. They are thus among the most prevalent kinds of blockchain oracles.
Exchange rates, pricing of digital assets, and real-time flight information are just a few of the types of data that software oracles frequently provide.
Some smart contracts require interaction with the outside world. Hardware oracles are intended to gather data from the real world and provide it to smart contracts. Such data can be transmitted from Electronic sensors, barcode scanners, and other information-reading devices.
Simply put, a hardware oracle translates real-world occurrences into digital values that smart contracts can comprehend.
An illustration of a hardware oracle can be a sensor that determines if a cargo aircraft has arrived at the airport. If it does, it transmits the data to a smart contract in order to make judgments.
Inbound and Outbound Oracles
Inbound oracles send information from external sources to smart contracts, whereas outbound oracles transfer information from smart contracts to the outside world.
For example, an inbound oracle might inform a smart contract about the temperature being measured by a sensor. A smart lock can be used as an example of an outbound oracle. The smart contract notifies a mechanism that opens the smart lock by sending this information via an outbound oracle as soon as the money is deposited to a specified address.
Centralized and Decentralized Oracles
A centralized oracle is the only source of data for the smart contract and is managed by a single entity. It can be dangerous to rely just on one source of information because the oracle's owner might determine whether the contract will work. Also, the smart contract will be directly impacted by any harmful interference from a bad actor. The primary issue with centralized oracles is that they have a single point of failure, which reduces the contracts' resistance to weaknesses and intrusions.
Decentralized oracles and public blockchains share a common goal of avoiding counterparty risk. By not relying on a single source of truth, they improve the accuracy of the data supplied to smart contracts. Decentralized oracles can also be referred to as consensus oracles because the smart contract consults several oracles to assess the validity and accuracy of the data.
While decentralized oracles strive for trustlessness, it's crucial to remember that, like trustless blockchain networks, they don't entirely get rid of trust but rather spread it among many users.
An oracle created specifically for use by a single smart contract is known as a contract-specific oracle. This means that a proportionately large number of contract-specific oracles must be created if one plans to implement numerous smart contracts.
It is considered to be exceedingly time- and money-consuming to maintain this kind of oracle. This strategy can prove to be quite unworkable for businesses that need to pull data from a number of sources. On the other hand, developers have a lot of freedom to customize contract-specific oracles to meet unique requirements because they can be created from scratch to serve a particular use case.
Oracles can occasionally be people who have specific expertise in a certain area. They are able to gather information from numerous sources, investigate its veracity, and convert it into smart contracts. Since human oracles can use cryptography to confirm their identity, it is unlikely that a fraudster will pretend to be them while supplying tainted information.
Blockchain Oracle Use Cases
Oracles are used by smart contract developers to create more complex decentralized apps for a larger variety of blockchain use cases. Although there are countless potential outcomes, the most adopted use cases of blockchain oracles are shown below.
Decentralized Finance (DeFi)
Oracles are necessary for a significant section of the decentralized finance (DeFi) ecosystem to access financial information regarding assets and markets. Decentralized money markets, for instance, employ price oracles to assess users' borrowing capacity and evaluate whether their holdings are undercollateralized and at risk of liquidation. Similarly, automated market makers (AMMs) employ price oracles to assist concentrate liquidity at the current market price to increase capital efficiency. Synthetic asset platforms use price oracles to link the value of tokens to real-world assets.
Dynamic NFTs and Gaming
Smart contracts can also be used for non-financial purposes with the help of Oracles, such as with dynamic NFTs—Non-Fungible Tokens that can alter in appearance, value, or distribution depending on the time of day or the weather. Compute oracles can also produce verified randomness, which projects can utilize to give NFTs randomized characteristics or to choose random winners in high-demand NFT drops. Verifiable randomness is also used in on-chain gaming applications to produce more captivating and surprising gameplay elements, such as the emergence of random treasure boxes or random matchmaking during a tournament.
Access to physical sensors, web APIs, satellite images, and legal data are made possible by insurance smart contracts, which use inbound oracles to confirm the presence of insurable events during claims processing. Using other blockchains or conventional payment networks, outbound oracles can give insurance smart contracts a mechanism to pay out on claims.
The widespread use of blockchains depends on a dependable system that enables communication between smart contracts and the outside world. Without blockchain oracles, smart contracts would be forced to rely solely on knowledge that already exists within their networks, greatly reducing their potential.
Decentralized oracles may create safety nets that would significantly reduce systemic risk in the blockchain ecosystem. For the blockchain ecosystem to develop, blockchain oracles continue to be one of the fundamental building blocks that must be applied in a secure, dependable, and trustless manner.
About Orochi Network
Orochi Network provides missing building blocks for Decentralized Gaming and Metaverse, the first infrastructure that provides Verifiable Computation.
We allow computation to be processed off-chain at zero cost without sacrificing decentralization. Using Zero-Knowledge Proof to prove and verify the computation, projects can inherit the solutions to be verified on-chain by using smart contracts efficiently.
About Orochi Network
Orochi Network is a cutting-edge zkOS (An operating system based on zero-knowledge proof) designed to tackle the challenges of computation limitation, data correctness, and data availability in the Web3 industry. With the well-rounded solutions for decentralized gaming and metaverse applications, Orochi Network omits the current performance-related barriers and makes ways for more comprehensive dApps hence, becoming the backbone of Web3's infrastructure landscape.
Verifiable Random Function
Introducing Orochi Network - The Operating System For High Performance dApp And Metaverse
10 January 2023
Orosign Wallet 101: How to get started?
03 February 2023
Validity Proofs vs. Fraud Proofs: An Explanation
06 January 2023
Introducing Orosign Multisignature Wallet - A Self-Managing Mobile App For Digital Assets
06 January 2023
Introducing Orand: Your Trustless Source of Randomness
20 February 2023
Verifiable Random Function