The Complete Guide to Blockchain Oracles
Oracles are fully decentralized systems in the context of blockchain that are in charge of relaying on-chain data from the blockchain to the outside world and bringing outbound into the network. They can also be viewed as methods of bridging the gap between the off-chain environment and smart contracts.
Oracles serve a number of important purposes, including:
- Oracles monitor blockchains for any off-chain queries made by clients or smart contracts.
- Oracles take data from off-chain third-party sources like APIs, web servers, etc.
- Oracle formats off-chain data that has been extracted into a legible on-chain format.
- On-chain requests are formatted by Oracles to work with off-chain resources.
- TLS signatures, zero-knowledge proofs, and other cryptographic techniques are used by Oracles to verify the data that has been collected from external sources.
- Smart contracts receive the off-chain results and proofs from oracles.
- Before sending results to smart contracts, oracles make the necessary calculations, for instance, averaging the results by weight.
An analysis of Oracles' many aspects
Blockchain networks are solitary systems. They don't interact with any off-chain resources. As a result, they need Oracle's infrastructure as a link between the on-chain and off-chain environments. The term "Oracle Problem" is frequently used to describe this issue.
But first, let's examine why blockchains require Oracles.
Blockchain brains are virtual machines. They run programs and upgrade the machine's state accordingly. Synced executions are a requirement in order for nodes to come to a consensus. In other words, consensus cannot be obtained if different execution outcomes are returned by separate nodes.
Oracles eliminate volatility or non-deterministic outcomes by including external data as part of the transaction's data payload.
Blockchains also include the idea of smart contracts, which is crucial. These contracts have the ability to run extremely simple code and provide binary outcomes.
There are a number of reasons why contracts rely on such sparse information:
- Storage for ledgers is constrained.
- Complex calculations have a very high computational cost.
- Reaching a consensus between nodes might become extremely difficult if they start to operate on all inputs independently.
- Smart contracts should limit their access to off-chain resources and external data for security and reliability reasons.
- Scalable solutions with limitless operations and data sources are challenging to develop.
The difficult calculations off-chain are handled by oracles. They extract data from the blockchains, perform calculations, and carry out necessary modifications. As a result, they solve issues with computing, memory, governance, encryption, and scalability.
Types of Oracle
In general, Oracles are in charge of carrying out off-chain actions and relaying the outcomes back to the blockchain. There are essentially two types of oracles.
1. Oracles of data
2. Oracles for computation
Oracles of data
These oracles attempt to insert external data into the blockchain, as is clear from the name. Numerous design patterns are possible for these oracles. They consist of:
- Immediate Read: offers data needed for immediate action. Anyone who needs the information can directly call the oracle contract by making a request call after the data has been stored once in oracle's storage. An illustration of such an oracle is the university's system for tracking accomplishments.
- Request-Response: gives a lot of information to those that ask for it. The response from this kind of oracle is typically too large to be recorded in smart contracts storage. As a result, these oracles are made to function with both off-chain infrastructure and smart contracts that run on chains. The market price feed for the top 1000 cryptocurrencies is an illustration of such an oracle.
- Publish-Subscribe: supplies subscribers with a broadcast service. Over time, this data is frequently susceptible to modifications. Contracts must check this data frequently for updates. An illustration of such an oracle is a feed with specified asset prices.
Heavy calculations are carried out off-chain using computational oracles. Then, they will provide the blockchain merely the results. Off-chain computations transfer the workload away from the blockchain. As a result, it reduces both execution costs and time.
Computational Oracles can be implemented in a variety of ways.
- Cryptlets: Incoming and outgoing communications are automatically signed, validated and proven via encrypted capsules with the CryptoDelegate linked to them that hide away the technology, such as I/O. Consolidated, multiphase, and multi-blockchain transactions are supported via cryptlets.
- Hosted Virtual Machines in the Cloud: cloud-hosted dedicated services. They take client input, perform computations, and then provide the results. The backbone of these systems primarily utilizes technologies like pods, IPFS, and docker files. These oracles are not distributed, though.
- Verification Games: Decentralized applications use the blockchain to regulate the rules of the verification game while paying for verifiable computation to be conducted off-chain. As a result, any computation task can be securely carried out via trustless smart contracts.
Design considerations for Oracle's architecture
In what ways do Oracles give data to smart contracts?
These 3 stages are often followed for transferring off-chain data into smart contracts:
- Data is gathered by Oracle from an off-chain data source, for instance, a weather station.
- Oracle uses a signed message to send the data it has obtained to the chain.
- Oracle makes data accessible by storing it in the smart contract's storage.
When the information is stored in a smart contract, other contracts can access it by activating the Oracle smart contract's "retrieve" function, or direct access to Oracle's storage.
How do Oracles guarantee data integrity and authentication?
There are various methods for ensuring data integrity.
- Authenticity Proofs: Using this method, the trust is transferred from third-party modules like attestors or auditors to oracles and smart contracts. These modules employ methods like proofs that are digitally signed to provide authentic evidence. Smart contracts check those proofs once they are given to them before carrying out any actions.
- Trusted Execution Environment (TEE): This technique applies Hardware-based secure units to guarantee data integrity. Numerous authentication capabilities, including attestation, CPU Security, and validated proofs, are typically used by the specific hardware used for this purpose.
How do Oracles support decentralization?
Decentralization is one of the key traits of the best blockchains. With distributed ledgers, the network's transactions, governance, and consensus are all attempted to be decentralized.
The most popular and widely used architecture approach to address oracle decentralization challenges is probably Decentralized Oracle Networks (DON).
These networks typically exhibit the following traits:
- There are several nodes in them. There is not a single point of failure as a result.
- They have systems in place for node-to-node consensus. Therefore, corrupted nodes will suffer consequences and have no influence over final judgments. They gather information from several data streams and use a variety of processes, such as weighted averages, to guarantee the best level of accuracy in the outcomes.
How do Oracles defend against manipulation attempts?
Oracle use can be risky if outside data is changed by attackers. Consider the following case:
The cost of a particular asset is necessary knowledge for a smart contract. For this, an oracle is employed. The asset's current price is then attempted to be extracted from the cost input of a decentralized exchange by the oracle. The attacker also uses that trade to get a quick loan. As a result, the oracle's prediction will be wildly wrong and the price will change greatly.
Oracles and smart contracts both employ several methods to solve this issue:
- Since it is more difficult to attack numerous sources, smart contracts use a median of multiple oracles.
- Weighted average tactics are employed by oracles. They attempt to obtain information from various sources and give it weight. A composite index of all those project resources will be the end outcome.
- Before sending the results to smart contracts, oracles use validator/verifier nodes. Before any data is sent to smart contracts, this body is responsible for confirming its accuracy and coming to a decision.
Few well-known oracle projects
An Oracle project called API3 is supported by decentralized APIs (dAPI). These APIs take advantage of all the regular APIs' best practices in order to meet the demands of smart contracts, such as security and data integrity.
In this concept, API providers serve as the first-party oracles by directly providing oracle services to any external contracts. In such an architecture, the Oracle network is supervised and audited by a decentralized governing body. The project leverages an API3 token for regulation, encryption, and cost structure utilities to do this. Voting, rewarding stakeholders and API providers, and paying for dApps fees all require the use of these tokens.
Three fundamental resources are offered by Chainlink, a decentralized oracle network (DON): network, memory, and computing.
A DON committee is made up of numerous nodes. This committee is responsible for carrying out all tasks involved in adding resources from off-chain to blockchains.
Every node has two different integrated program types:
1. Executables: independent programs that guarantee fast performance and support private computations.
2. Adapters are computer programs that connect DON to outside resources and are accessible through executables. The primary organization in charge of obtaining data from off-chain suppliers in these programs.
Tendermint and Cosmos SDK power Bandchain, an Oracle blockchain. Bandchain leverages Byzantine Fault Tolerance to help block validators come to an agreement.
Oracle scripts are at the core of Bandchain. These are the applications that are used to request data from other sources. They are also in charge of compiling the final outcome from reports of raw data.
A chain of validators receives the requests. Afterward, these nodes make an effort to obtain data from other sources. They hand it off to Oracle programs once they receive the outcome. The script then goes on to add these numbers together to produce a single outcome. The evidence is completed with Oracle data. The presence of the end outcome of the data query on BandChain is demonstrated by this Merkle proof.
First published on Oct 18, 2022