Blockchain oracles are third party services providing external information via a smart contract. They act as bridges between the blockchains and the world outside.
Scalability and interoperability make for the crypto space’s two holy grails. The main characteristic of interoperability is, being able to communicate and share information between different software effectively. Oracles are a powerful tool that can communicate with external data sources and provide interoperability between different blockchain.
Why interoperability matters for Blockchain Oracles
- Inside the decentralized space, there are many centralized points of failure currently. So, e.g., The exchanges act as a portal between the decentralized space and the centralized. However, they are still under attack from hackers because they are highly vulnerable.
- To be successful, blockchains must interact with legacy systems such as financial institutions, etc. Keeping a robust point of contact between the two is crucial.
- Initially, the community thought chain maximalism would govern the smart contract ecosystem, i.e., one dominant chain that hosts many smart contracts. But we already know there are several smart contract platforms out there. Knowing how to “speak” to one another is crucial to achieving full functionality for these platforms.
Categorisation of Blockchain oracles
Blockchain projects can utilize two types of interoperability:
- On line
Interoperability on the Chain
This approach makes use of a third blockchain as a link between two blockchains. This method is used in projects such as AION, Wanchain, and ICON. The next three are the most common on-chain interoperability approaches:
- Hub and Spoke: Famous by AION, connecting blockchain in this system serves as a central hub linked to the other blockchains or spokes.
- Decentralized exchange: The building of a decentralized exchange can create interoperability between two separate projects.
- Bridges: The blockchain serves as a general-purpose bridge between communication and messaging aids in this process.
Interoperability off site
This method uses middleware or off-chain systems to facilitate interoperability.
- Atomic swaps: Atomic swaps are a decentralized way of exchanging two commodities without a centralized exchange.
- State Channels: Layer-2 implementations such as state channels will allow atomic swaps and off-chain interactions.
- Operating Framework: A blockchain operating system allows cross-chain communications and atomic exchanges by running on top of the blockchains involved.
- Oracles: Oracles can also enable wide-ranging cross-communication across blockchain and business systems.
Besides that, we can also categorize oracles into oracles with software and hardware:
- Oracle Software: The information relayed inside the Oracle software comes from online sources such as websites, backend APIs, or even other smart contracts. The type of information here can range from stock prices to data on sporting events.
- Oracle Hardware: Hardware oracles use IoT devices to monitor and validate data in the real world before submitting them to the smart contract.
Why do we need Oracles at Blockchain?
Smart contracts designed to execute irreversible operations. The details fed into the contract must, therefore, come from a fairly trustworthy source. This is why it can be a bit of a dilemma when data comes from an external source. It does increase the number of use cases exponentially on the flip side, however.
The state of the world is claimed by oracle signs and uploaded to the blockchain. Blockchains seem to exist in their lonely existence, cut off from the rest of the world altogether. An oracle can link the blockchain to the real world by making relevant information accessible to it. The information may be extracted or aggregated by one or more oracles from one or more reliable sources. Let’s take a simple example of how oracles function.
- Alice and Bob have placed a bet on who will win the NBA finals.
- Alice believes LA Lakers will win while Bob bets on the Milwaukee Bucks.
- They are signing the deal after deciding on the payouts by locking their funds in a smart contract. Based on the results, the smart contract releases funds to the winner.
- Now, how exactly does the contract know who the match-winner was? It is up to the oracle to feed it with the relevant information.
- The oracle queries a trusted API to determine which team won to relay this information to the smart contract. Based on the result, the contract then transfers the funds to Alice or Bob.
- Without the oracle doing its job, there’s no way the smart contract will know who the match’s winner was.
Use cases on blockchain
1. Market Prediction
Decentralized prediction markets such as Augur and Gnosis are leveraging “crowd knowledge” to predict the markets’ future state. Those markets must capture knowledge through multiple oracles or settlements of events off-chain.
In the age of Decentralized Finance (DeFi), the fusion of smart contracts and finance has given way. These products need access to trustless data feeds, which oracles may provide.
3. Insurance Policy
One can purchase insurance products over the blockchain via oracles. Because the biggest problem in insurance is fraud, blockchain decentralization, and oracles reliability are a perfect combo to solve this problem.
To ensure reliable location mapping for dApps to track shipments, Oracles can replace existing, centralized GPS systems.
5. Putting the “stablecoins” stable in
Dai stablecoin by MakerDAO uses a network of multiple Oracles to report the price of Ether to it continually. We need to be continuously aware of the market to know if their collateral needs to be combined or liquidated to keep Dai’s price stable.
How to preserve the security of Blockchain Oracles?
Four strategies can be used by oracles to ensure its reliability:
- Multi-source info.
- Different Oracles.
- Mechanisms of Reward.
- Trusted environment in which to execute.
Diverse sources of data
If your oracle collects info from multiple data sources, there is little likelihood of it receiving misinformation. The oracle itself may act as a point-of-failure, however.
Another solution is to collect data using multiple oracles that negates the “single-point-of-failure” problem. The risk here, however, is that a majority of those oracles may have compromised information sources.
Mechanism for Incentives
Oracles can take a page out of Casper’s protocol and include a ‘stake-slashing’ mechanism to ensure the actors involved are acting honestly. The key here is to incorporate a tokenomics form that forces the oracle network nodes to do honest work and act well. If they do well, they get a reward. If not, there will be punishement through a slashing mechanism.
Trusted environment for execution (TEE’s)
TEEs allows for the execution of an application in a secluded environment called an “enclave,” which provides hardware security. The Encyclical:
- Ensures project honesty.
- Keeps traffic confidential.
- It allows the application to read memory outside the enclave and write it down. In other words, it will show its reliability and job dignity without the need to pour out precisely what they do.
Promising blockchain oracles
We are going to be bringing three oracle ideas under the microscope. These are as follows:
- Gates RIF.
ChainLink is a network of decentralized oracles based on Ethereum. It aims to be a secure middleware blockchain intending to connect various smart contracts across blockchains. On 30 May 2019, the network went live. The company that is behind this is called “SmartContract.” ChainLink raised a whopping $32 million in its ICO back in September 2017.
ChainLink plans to create smart contracts to interact securely with resources outside of the blockchain, such as cryptographically secure data feeds, and facilitate interoperability between blockchains. It is currently focused on creating a decentralized network of oracles compatible with the blockchains Bitcoin, Ethereum, and Hyperledger.
ChainLink Network: Off and On Chain
The ChainLink protocol uses components, both in-chain and out-chain.
- Filters the oracles based on the metrics a party requests to a smart contract.
- Collects and sorts the oracles corresponding to the SLA queries using reputational and aggregated models.
- Provides a collective final result based on query.
- This component is composed of oracle nodes connected to the Ethereum network. These nodes respond independently to specific requests from outside the chain.
- The off-chain nodes that meet specific, pre-determined requirements gather the information that these contracts require.
- ChainLink acts as a middleman for re-routing and allocating data at a low cost.
- For their services, out-chain nodes are compensated with the native Connection token.
Augur is a trustless oracle, decentralized, and market platform for prediction. It leverages crowd wisdom to speculate about and report any event’s objective outcome.
Prediction markets are speculative markets enabling users to buy and sell shares in an event result. Suppose you have specialist expertise in a given area. So, e.g., A match for Basketball. You wager on a favorable outcome by considering various factors.
How does Augur function?
There are three types of people who hire augur:
- The Reporters called Oracles: Reporting on the outcomes of their fields of interest. They comment about the outcome when an occurrence is a past maturation. They risk losing 20 percent of their REP (native Augur tokens) if they report wrongly or do not report at all. The augur value is directly proportional to the reporter’s rating. Why? For what? Because if many of the reporters are dishonest, no one will want to use augur, decreasing demand significantly. This forces all reporters to keep themselves honest.
- The Wagerers: Based on the reporters’ reports, they bet on the future of markets.
- The Market Creators: The reporters will create the markets to report on and earn market fees.
Reporting takes place in 2 phases. The reporters submit their report to the network within the first month of the event’s completion, which is tightly secured and kept away from the public. The second step occurs a month later, where the results are published in an open ledger, which is safe for everyone to see. We’re reaching a final consensus when that is reached.
Moving on from the consensus
- The wagerers get their reward for placing their bets.
- The reporters who have written honestly are getting wagerers’ fees.
- Reporters who have not reported correctly get deducted 20 percent of their REP, which, in effect, goes to reporters who have reported fairly and accurately.
Rootstock (RSK) is a smart contract network, linked via sidechain technology to Bitcoin’s blockchain. Rootstock lets you build Ethereum-compatible applications (the web3 / EVM / Solidity model) while still enjoying the protection provided by Bitcoin’s blockchain. It is a combination of, at its very core:
- A Turing-complete, resource-accounted virtual deterministic machine (for smart contracts) is compatible with EVM from the Ethereum.
- A two-way pegged bitcoin sidechain (based on a strong federation for BTC denominated trade)
- A SHA256D merging-mining consensus protocol (relying on Bitcoin miners for consensus security) with a block interval of 30 seconds. (For prompt payments).
Rootstock can also use its software platform-the Open Source Rootstock Infrastructure Framework (RIFOS), to help create a stable economic network on top of Bitcoin, as a decentralized AWS. It would make the use of blockchain technology simpler by making it as easy as possible for all. When it comes to RIFOS, bear in mind the following features:
- As long as a product is compliant with the underlying protocols, developers can integrate it seamlessly within the RIFOS ecosystem.
- All of the individual RIFOS components were designed to maximize potential benefits for those who wish to offer their infrastructure services within the protocol’s ecosystem.
- The protection offered by the Bitcoin Network protects all of the components.
- Its protocols should provide network effect triggering mechanisms and economies of scale.
- The bulk of the services running in RIFOS are accessed using a single token (RIF).
A brief overview of RIF gateways
RIF Gateways provides an oracle network that allows for secure and manipulative interactions with the outside world. It proposes an interface layer that unifies access to oracle services and cross-chain integrations, providing blockchains with an implementation-agnostic protocol for internal and external data use. Here are a few points concerning RIF Gateways to remember:
- Construct bridges across blockchains.
- It allows data providers and consumers to make secure and standardized transfers of data.
- Supports a broad range of models for data consumption, subscription, and payment.
RIF Gateways offers 3 distinct oracle services:
- Data services: Accessing outside blockchain data.
- Triggers service: External data is consumed from within the blockchain.
- Scheduler service: Request a blockchain transaction to be executed in the future.
1. Infrastructure for Data
A data service offers a specific form of data from the outside world. External data may come from a single data source or multi-source network. And it works like this:
- A data service creator and offerer is named “Data Service Provider.”
- Consumers may select between different types of data services and then communicate with the corresponding data service provider’s smart contract to get the external data.
- In their smart contracts, the service provider has to implement the Data Service interfaces.
- The Provider will update their data regularly because their user may need the latest data or the one published some time ago.
How does a Provider-Consumer interaction work?
There are two ways a consumer can use to consume data from the provider-a direct pull model or a subscription service.
Consumer pays per-quarter for the data. The requested data are collected directly from the provider. This is a slower and more expensive setup.
A consumer pays for access at a fixed price. Serving several customers with a single piece of data enables the Service Provider to share the cost of gathering external-world data from all subscribers. RIF has two subscription models:
- On-demand: As long as the subscription is valid, the Consumer asks the Provider for the value as needed.
- Push: Provider regularly transfers the latest data to the subscribers
2. Services to Cause
A trigger service allows the Provider to collect information from inside the blockchain and to offer it for a price to the user. On the Provider’s API, the consumer can build his own notification solution. The Trigger Service features are as follows.
- Each Trigger Provider should have a unique domain name associated with it. That ensures user-friendliness.
- Providers must conform to a predefined interface designed for third party applications to consume.
- Consumers can choose between a single supplier or subscribe to a set of suppliers.
In the blockchain, the Provider may provide notification service for such smart contracts or events. He does this by notifying the observance of a specified series of events generated by the contract.
The user may also create a trigger specifically for his or her own needs. They must specify the source of the events they wish to be notified of to the Provider, e.g. Smart address of the deal.
- Also, a non-technical-user can create their own notification service.
- The Provider allows customers to decide which will be the next action until they receive a matching event to cause any action.
- Consumers are free to set the list of events that the Trigger Provider must notify.
How does a Provider-Consumer interaction work?
The pull and subscription models are available in the trigger service
The consumer specifically asks for a notification about one specific event.
A consumer pays a predefined price for the service, just like with Data Services. However, only the push subscription model has been triggered.
3. Timing of transactions
The transaction scheduling service is a decentralized solution that enables a client to program future on-chain transaction executions. As with Data Services and Trigger Services, by registering a new scheduler service to be discovered through the RIF marketplace, new scheduling service providers can join. Consumers may be in-house / on-chain, or out-of-chain.
How does a Provider-Consumer interaction work?
Pull, and subscription models can also be provided by the scheduler company.
The user pays the necessary amount after demanding a single transaction schedule for a delegated execution. You can schedule execution for a specific time and a given “execution window.”
Consumers can subscribe to delegate the execution of a particular function repetitively. Recurrently, the customer pays a fixed price for performing a task. The RIF Scheduler Services protocol proposes that you only have the push subscription mode to delegate a repeat execution.