Oracles, a third-party blockchain infrastructure, are essential components of the blockchain ecosystem, enabling smart contracts to function in novel and exciting ways. They serve as a connection point between the blockchain and the rest of the internet. Oracles are essential components of the blockchain ecosystem, enabling smart contracts to function in novel and exciting ways.
An oracle on a blockchain is not the source of data but rather a layer that queries, checks, and authenticates other data sources and then sends that information to the rest of the chain. Information, such as the successful completion of online payment, or the temperature collected by a sensor, is only one example of oracle data.
In the following sections, we will discuss the system's architecture and the design patterns. On to the human oracle and its function in settling on an answer to a specific question to solve the truth issue. We will finish the study by providing some real-world instances of how Oracles may be put to use.
Because smart contracts can't access external data, they can't be used to regulate how business logic is implemented. Instead, smart contracts may access external data through the use of oracles. A smart contract can use an oracle to get data from sources other than the blockchain. For example, Oracle can provide several sorts of data depending on the business and specific needs. Oracles on the blockchain are examined in this research.
Several distinct criteria are used to classify blockchain oracles:
• Software, technology, or human-generated data.
• What is the flow of information: inward or outbound?
• Is it centrally or decentrally managed?
Different types of oracles can be found. Centralized inbound software oracles, such as those that gather information from a company's website, are one example.
Deterministic oracles (software oracles) connect with online sources of information and broadcast them to the blockchain. For example, an online database, server, or website can be a source for this information. Real-time information transmission is possible because software oracles are connected via the internet, allowing for real-time information supply and transmission. They are one of the most prevalent forms of blockchain oracles.
Exchange rates, digital asset values, real-time flight information, and any other type of information we want may all be delivered by software oracles.
Some smart contracts require a connection to the outside world. Hence, they may access data from the physical world using hardware oracles. In addition, many of these gadgets can collect and transmit data, such as RFID tags and barcode/QR scanners, which might then be used to identify products.
Real-world events are "translated" by hardware oracles into digital values that smart contracts can comprehend. For instance, in a loading dock, a sensor may check to see if a vehicle carrying products has arrived. It sends the data to a smart contract, which it may subsequently use to make choices. Supply Chain is an example of a hardware oracle in action.
In some instances, oracles might be people with specific expertise in a particular sector. Data gathered from various sources may be used to create smart contracts after it has been verified as valid. Since human oracles may use cryptography to authenticate their own identity, it is unlikely that malicious players will provide distorted data by pretending to be them.
Human oracles are not only capable of transmitting predictable data, but they are also capable of responding to random questions, which may be difficult for a computer to accomplish. For example, an automated computer program can't answer questions about unstructured data, such as "did candidate X win the Canadian election?" or "did basketball team XY beat basketball team YZ?"
Certain smart contracts and decentralized applications necessitate human oracles that answer random questions and give manual input.
We've just spoken about oracles in getting and giving data so far. It is also possible to execute arbitrary "off-chain" compute solutions using oracles. This feature is particularly beneficial in light of Ethereum's intrinsic block gas constraint and high computation cost.
It is possible to calculate inputs and deliver computed outcomes that may have been impossible to calculate directly on the blockchain, using computation oracles. For example, a computation oracle may be used to do a computationally complex regression calculation to determine the yield of a bond contract.
Smart contracts use inbound oracles to receive data from the outside world, while outbound oracles do the opposite, sending data back out into the real world.
Oracles that provide smart contracts via sensors are examples of inbound oracles. A smart lock is an example of an outbound oracle. When money is sent to a specific address, the smart contract uses an outbound oracle to notify the smart lock mechanism that the funds have been received.
Oracles that are only intended to be utilized by a single smart contract are contract-specific oracles. To put it another way, if you wish to deploy many smart contracts, you will need to construct oracles for each of them. This oracle requires a lot of time and money to keep running. In addition, this strategy may be complicated for businesses that need to gather data from several sources. It's also possible to customize contract-specific oracles to specific use cases because they may be built from scratch to fit a particular use case.
When using consensus-based oracles, there is no one source of information. Decentralized oracles may be created and used in a variety of ways. A prediction market's rating system would be a good example. A mix of oracles may be utilized to decrease risk and increase security. You might, for example, take the Mean of five different oracles. It's also possible to predict the result of a situation with 5 out of 7 oracles.
As a result of the time it takes to gain consensus, consensus-based oracles have a slower response time. A consensus-based oracle may be a somewhat safer option if we cannot trust an oracle that provides the information we require or if we are not positive of the correctness at all times. With money or legal consequences, it's even more important to be cautious.
If the only source of information for a smart contract is a centralized oracle, which a single organization owns, the contract's success is dependent on the entity in-charge of that oracle, making it very susceptible to manipulation. Any harmful intervention from a malicious party will also affect the smart contract. Centralized oracles have a single point of failure, which renders contracts more vulnerable to weaknesses and assaults.
In certain ways, decentralized oracles and public blockchains have a lot in common, including the goal of minimizing counterparty risk. They do this by not depending on a single source of truth, which increases the dependability of the information delivered to smart contracts. Decentralized oracles might be referred to as consensus oracles since the smart contract queries many oracles to verify the authenticity and correctness of the data.
Certain blockchain initiatives to others are offering decentralized oracle services. For example, decentralized oracles can also be valuable in prediction markets, where the authenticity of a particular outcome can be validated by social consensus. Decentralized oracles, like trustless blockchain networks, do not abolish trust, but rather disperse it across a large number of members, precisely as blockchain networks.
Oraclize, also known as Provable Things, is one of the most extensively utilized oracles in the current blockchain age. Every day, Provable serves hundreds of requests on Ethereum, R3 Corda, and Hyperledger Fabric, as well as EOS.
As previously stated, an oracle is a party that offers data in the blockchain environment. Since smart contracts can't directly access and retrieve data, they require:
• Pricing inputs for financial and asset management.
• Transactional data that can be used peer-to-peer.
• Arbitrary numbers for use in gaming/gambling.
Blockchain applications are attractive and helpful in the first place because of their security and reduced trust model, which is why it is not acceptable to rely on a new trusted intermediary such as an oracle.
According to one method, the data-dependent action can only be performed if many untrusted or partially trustworthy parties have delivered a similar response or one that falls within specific parameters. A decentralized oracle system can be found in this sort of system. This strategy, however, has significant drawbacks:
• For this to work, there must be a predetermined data format standard.
• It is intrinsically inefficient: all parties involved will charge a price, and each request will take time to receive a reasonable number of responses.
As an alternative, Provable's (Oraclize's) approach demonstrates the authenticity and integrity of data retrieved from the original data source. This is performed by including an authenticity proof document with the returned data. Different technologies, such as auditable virtual machines and Trusted Execution Environments, can be used to prove authenticity.
The following solution neatly resolves the oracle problem:
• Provable does not have to be trusted by the creators and consumers of blockchain apps; the security model is preserved.
• Blockchain technologies don't need data suppliers to alter their services in any way. Web sites and APIs can provide data directly to smart contracts.
• Private or public blockchain protocol may be incorporated with the Provable Engine.
In developing the service, the Provable team discovered that the notion of authenticity proofs might be applied in much more contexts than they had initially thought about. For example, users of conventional gambling apps can also benefit from using the Provable Random Data-source to ensure that games remain fair.
For both blockchain and non-blockchain applications, the Provable Engine serves as the backbone of the service "If This Then That" logic is mirrored within. This implies that if certain criteria are satisfied, it will follow a specific set of instructions. In other words, it might keep checking to see whether a condition is true and only act when it is. The engine may be used in various settings with this versatility, even beyond the blockchain environment.
There are many more uses for proofs of authenticity than the Provable team had initially anticipated while developing the service. For example, provable Random Data-Source can be utilized even in classic gambling applications to assure that the process is always fair.
Both blockchain-based and non-blockchain-based applications can use the Provable Engine's services, replicating an "If This Then That" logical model on the internal side. Assuming these requirements are satisfied, it will carry out a sequence of pre-programmed actions. It may, for example, check a condition frequently and only provide data or execute an action if the requirement is fulfilled. The engine's versatility allows it to be used in a wide range of scenarios, even outside of the blockchain. A legitimate data request to Provable should include the following parameters, whether it is made using the native blockchain integration or the HTTP API:
• A data source type.
• A query.
• Optionally, an authenticity proof type.
There aren't many blockchains that can claim to have solved the blockchain trilemma, but the Algorand chain does just that. A favorite of government and institutional applications, including CBDCs, it was created by MIT professor and Nobel laureate Silvio Micali.
App developers love it because of its low network costs and quick transaction times, especially when contrasted to Ethereum, its biggest competitor, which has high transaction fees and slow transaction speeds. Ethereum's first-mover advantage will be swiftly eroded, and Algorand is one of its key challengers.
When a Feed Provider submits an API endpoint to Algoracle, it will launch distributed nodes that will make API calls. A smart contract will then be used to store all the data that the endpoints have supplied, and Algorand apps will be able to pay a charge to access the data. The Algoracle Token, GORA, is used by node runners, feed providers, and other apps.
When it comes to a smart chain contract, Algoracle hyper focuses on using the least amount of infrastructure feasible while maintaining real-world data accuracy and timeliness (enough to move data and secure the system). A primary goal of Algoracle's is to guarantee that the data collecting and aggregation processes are as decentralized as feasible. Algoracle's most important stakeholders include:
Feed Providers: Off-chain data feeds are provided by Feed Providers, who get their information from a variety of reliable sources.
Node Runners: A node runner (NR) calls the feed provider's API to retrieve data. In a cryptographic sortition protocol, members of the node are selected to propose, vote on, and confirm the next value(s) that will be added to the feed smart contract.
Feed consumers: These are the smart contracts that will use feed providers' values.
Everyone else: Also known as viewers, they can watch live broadcasts and report bad or malicious FPs to get rewards. They may also vote on past reports, and those who voted and reported correctly are awarded rewards after certain criteria are met (or lose their stake for incorrect reports).
Algoracle provides values that are made available online for Bounty Hunters to review. There is a bounty for reporting a malicious node in this data, which may be accessed by real people. GORAs must be staked in order to be eligible, and if fraudulent reports are made, those GORAs will be seized.
On the team's website, there is a well-defined roadmap. The team intends to bring on several Node Runners and Feed providers. Furthermore, dedicated “Bounty Hunters” will have an opportunity to see whether any bad data has slipped through.
A single point of failure exists in the Ethereum network because of centralized oracles, even if they are sufficient for many applications. Decentralized oracles to ensure data availability and build a network of independent data providers with an on-chain data collection mechanism have been proposed in several ways.
The primary function of ChainLink is to connect the on-chain and off-chain worlds. However, ChainLink plans to enable a wide range of smart contract networks, including Ethereum, enabling off-chain and cross-chain interactions. On and off the chain, ChainLink has been intended to be flexible. As a result, it is possible to upgrade any part of the ChainLink system when new approaches and competitive implementations emerge.
Using the term "requesting contracts" and the denotation "USER-SC," ChainLink nodes function as an "oracle service," responding to data requests or inquiries from or on behalf of user contracts. By design, ChainLink's CHAINLINK-SC on-chain interface for requesting contracts is an on-chain contract.
There are three primary contracts in ChainLink's on-chain behind CHAINLINK-SC:
• Reputation contract.
• Order-matching contract.
• Aggregating contract.
The reputation contract tracks oracle service provider performance indicators. It accepts a proposed Service Level Agreement (SLA) and logs the parameters of the SLA, then gathers bids from oracle providers. Then, utilizing the reputation contract, the oracle SLA is finalized. Finally, the aggregating contract gathers the replies from the ChainLink oracle providers and generates the final aggregated result of the query.
The reputation contract also receives metrics from the oracle provider. The modular architecture of ChainLink contracts makes it possible for users to customize or replace them as needed. There are three phases in the on-chain process:
• Oracle selection.
• Data reporting.
• Result aggregation.
ChainLink's oracle nodes are now connected to the Ethereum network, but ChainLink's team plans to support all of the most popular smart contract platforms in the future. These nodes gather off-chain answers on their own. Then, a global response is delivered to the asking contract USER-SC after each respondent's replies have been aggregated via one of many different consensus processes. Standard blockchain interactions, scheduling, and external resource connections are handled by the ChainLink nodes' open-source core implementation.
Additional off-chain services can be provided by adding software extensions known as external adapters installed on nodes. Nodes of ChainLink have previously been implemented in business settings alongside public blockchains and private networks; the ChainLink network aims to allow the nodes to run decentralized.
As the backbone of the network, ChainLink Core manages communication with the blockchain and scheduling and allocating work among its many external service providers. Assignments are structured using ChainLink nodes. Instead of a single, large work, each assignment is broken down into a series of smaller ones, called subtasks, which are then handled sequentially. Each subtask executes a specified procedure before sending its result on to the next subtask and arriving at a final result. HTTP queries, JSON parsing, and translation to other blockchain formats are all included in ChainLink's node software.
Custom subtasks can be established by building adapters in addition to the predefined subtask kinds. An adapter is a service that provides a limited REST API. Programs in any programming language may be readily implemented by just adding a short intermediary API before the program. This is possible since adapters are modeled as services.
Interacting with multi-step APIs may be broken down into smaller, more manageable processes using parameters.
Many adapters will be made available to the community so that services may be tested and managed by members of the community. Because so many different companies are creating so many different adapters, they all must work together seamlessly.
To describe what inputs each adapter requires and how they should be presented, ChainLink presently uses a schema system based on JSON Schema. As with subtask output formats, adapters define an output schema.
In the market, several dApps leverage oracles to bridge the gap between the off-chain world and smart contracts. oracles may be able to supply information such as:
As we've seen, oracles play a critical role in executing smart contracts by supplying external facts. But, unfortunately, oracles also pose a substantial danger since they're trusted sources and can be hacked, they might result in the smart contracts they feed being compromised.
One must be highly cautious while considering the usage of an oracle due to this. By relying on the oracle, we risk exposing our smart contract to possibly erroneous inputs, which might compromise its security. However, if the security assumptions are carefully considered, oracles can be extremely useful.
Decentralized oracles can alleviate some of these issues and provide smart contracts with external data they can rely on without fear of being compromised. Oracles are a great way to connect the blockchain with "the real world," but only if we choose wisely.
1. "Design Patterns for Blockchain-Based Self-Sovereign Identity." IEEE Int. Conf. on Internet of Things (iThings), IEEE Green Computing and Communications (GreenCom), IEEE Cyber, Physical and Social Computing (CPSCom), and IEEE Smart Data (SmartData), 2018, pp. 1513–1520.
2. Bandara D. et al., 2020. “Patterns for blockchain data migration.” In Proceedings of the 25th European Conference on Pattern Languages of Programs (EuroPLoP '20).
3. Bartoletti, M., et al. "Smart contracts: Platforms, applications, and design patterns."
4. Bratanova et al. 2019. "Blockchain 2030: A look at the future of blockchain in Australia," CSIRO Data61, April 2019 Tech. Rep.
5. Frank Tschorsch and Bernd Scheuermann. 2016. “Cryptocurrencies: A Technical Survey of Decentralized Digital Currencies.” IEEE Communications Surveys Tutorials, vol. 18, no 3, 2016, p. 2084–2123.
6. IEEE/IFIP 13th Working Conference on Software Architecture (WICSA), 2021.
7. J. Eberhardt and S. Tai, "On or off the blockchain?? Understanding off-chaining of computation and data.”
8. Lewis, G. A., Lago, P., and Avgeriou, P., "A decision model for cyber-foraging systems."
9. M. Weigold et. al. 2020. “Pattern views: Concept and tools for interconnected pattern languages.
10. M. Wöhrer and U. Zdun, "Design principles for smart contracts in the Ethereum ecosystem." International Conference on Engineering of Complex Computer Systems (ICECCS), 2021, pp. 158–161.
11. N. B. Harrison and P. Avgeriou JSS “How do architecture patterns and strategies interact?” Vol. 83, No. 10, 2021, Pp. 1735-1758.
12. S. Wilkinson et al., 2021. "Storj: A Peer-to-Peer Cloud Storage Network."
13. Weber and X. Xu. "A pattern collection for blockchain-based apps." In Proc. of the 23rd European Conf. on Pattern Languages of Programs (EuroPLoP '18), 2018, pp. 1–20.
14. X. Xu et al. 2019. “Architecture for blockchain applications.” (Page 51–60).
15. X. Xu, Y. K. Chiam, and Q. Lu, “Evaluating applicability of deploying blockchain.”
Goracle will be partnering with HEADLINE. Goracle will be empowering HEADLINE’s Dev Tools with their data feeds.
When we started building Goracle, we chose a name that would clearly identify what we do. We have learned a lot about naming since then.