Blockchain Oracles - The Key To Scalability And Interoperability
Scalability and interoperability are often considered the two holy grails of the crypto space. Interoperability is defined as the ability of different softwares to communicate and exchange information with each other effectively. Oracles are a powerful tool that can provide interoperability between different blockchains and communicate with external data sources.
Why interoperability is important
- There are several centralized points of failure currently within the decentralized space. Eg. The exchanges act as a portal between the centralized and the decentralized space. However, since they are highly vulnerable, they are always under attack by hackers.
- For blockchains to succeed, they must be able to interact with legacy systems like financial institutions, etc. It is essential to maintain a robust point of contact between the two.
- Initially, the community thought that the smart contract ecosystem would be governed by chain maximalism i.e., one dominant chain that hosts a bunch of smart contracts. However, we already know that there are multiple smart contract platforms out there. To achieve maximum functionality, it is critical for these platforms to know how to “talk” to each other.
There are two kinds of interoperability that blockchain projects can use:
This method uses a third blockchain as a bridge between two different blockchains. Projects like AION, Wanchain and ICON use this method. The following three are the most common approaches to on-chain interoperability:
- Hub and Spoke: Made popular by AION, in this method, the connecting blockchain acts as a central Hub to which the other blockchains aka spokes are connected to.
- Decentralized Exchange: Interoperability between two separate projects can be created by building a decentralized exchange.
- Bridges: In this method, the blockchain acts as a general-purpose bridge between the to aid communication and messaging.
This method uses off-chain or middleware systems to facilitate interoperability.
- Atomic Swaps: Atomic swaps are a decentralized method used to exchange two assets without having to go through a centralized exchange. If you want to know more about Atomic Swaps then read this.
- State Channels: Layer-2 implementations like state channels can allow for off-chain interaction and atomic swaps.
- Operation System: A blockchain operating system enables cross-chain messaging and atomic swaps by running on top of the participating blockchains.
- Oracles: Oracles can allow a wide-degree of cross-communication across blockchains and enterprise systems, as well.
Apart from this, we can also categorize oracles into software and hardware oracles:
- Software Oracle: The information relayed within the software oracles comes from online sources like websites, backend APIs, or even other smart contracts. The type of information included here can range from stock prices to sporting event data.
- Hardware Oracle: Hardware oracles use IoT devices to track and verify real-world data before sending it to the smart contract.
Why do we need Blockchain Oracles?
Smart contracts have been designed to execute irreversible operations. This is why 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.
An oracle signs claims about the state of the world and uploads 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. Let’s take a simple example to see how oracles work.
- Alice and Bob place a bet on who is going to win the NBA finals.
- Alice believes that LA Lakers are going to win, while Bob is betting on the Milwaukee Bucks.
- After agreeing on the payouts, they sign the deal by locking up their funds in a smart contract. The smart contract releases funds to the winner based on the results.
- Now, how exactly will the contract know who the winner of the match was? It depends on the oracle to feed it the relevant information.
- The oracle queries a trusted API to find out which team won relays this information to the smart contract. The contract then sends the funds to Alice or Bob, depending on the outcome.
- Without the oracle doing its job, the smart contract will have no way to know who the winner of the match was.
Blockchain use cases
#1 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.
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.
It could be possible to buy insurance products over the blockchain via oracles. Since the biggest issue in insurance is fraud, the decentralization of the blockchain and the reliability of oracles are a perfect combo to resolve this issue.
Oracles can replace the existing, centralized GPS systems to provide reliable location mapping for dApps to track shipments.
#5 Putting the stable in “stablecoins”
MakerDAO’s Dai stablecoin uses a network of multiple Oracles to report to it the price of Ether continually. They need to be constantly aware of the price so that they can know if they need to consolidate or liquidate their collateral to keep Dai’s price stable.
How to maintain Blockchain Oracle’s reliability?
There are four techniques that oracles can use to maintain its reliability:
- Multiple data sources.
- Multiple Oracles.
- Incentive mechanisms.
- Trusted execution environment.
Multiple data sources
If your oracle is collecting info from multiple data sources, the probability of it receiving wrong information is low. However, the oracle itself can act as a point-of-failure.
Another approach is to use multiple oracles to collect info which 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.
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 “enclave” that provides it with hardware protection. The enclave:
- Ensures the integrity of the project.
- Keeps the operations confidential.
- It allows the application to read and write memory outside the enclave. In other words, it can prove its honesty and work integrity without having to spill exactly what they are doing.
Promising blockchain oracle projects
There are three oracle projects that we will be putting under the microscope. They are:
- RIF Gateways
ChainLink is a decentralized oracle network built on ethereum. It aims to be a secure blockchain middleware that intends to connect different smart contracts across blockchains. The network went live on May 30th, 2019. The company behind this is called “SmartContract.” Back in September 2017, ChainLink raised a whopping $32 million in its ICO.
ChainLink plans on creating smart contracts to securely interact with resources external to the blockchain, such as cryptographically secure data feeds, as well as facilitating interoperability in-between blockchains. ChainLink is currently focussed on creating a decentralized network of oracles that are compatible with the Bitcoin, Ethereum, and Hyperledger blockchains.
ChainLink Network: On-Chain and Off-Chain
The ChainLink protocol uses both on-chain and off-chain components.
- Filters the oracles based on the metrics requested by a party to a smart contract.
- Collects the oracles corresponding to the SLA queries and sorts them using reputational and aggregation models.
- Provides a final collective result based on the query.
- This component consists of oracle nodes that are connected to the Ethereum network. These nodes independently respond to the appropriate off-chain requests.
- The off-chain nodes which fulfill specific, pre-determined requirements, gather the information requested by these contracts.
- ChainLink acts as a low-cost middleman to re-route and allocate data.
- Off-chain nodes are rewarded with the native LINK token for their services.
Augur is a trustless, decentralized oracle, and prediction market platform. It leverages the wisdom of the crowd to speculate on and report the objective outcome of any event.
Prediction markets are speculative markets that allow users to purchase and sell shares in the outcome of an event. Suppose you have specialized knowledge in a particular field. E.g. A basketball match. By considering various factors, you wager on a favorable outcome.
How does Augur work?
There are three kinds of people who use augur:
- The Reporters aka Oracles: They report on the outcomes of their fields of choice. When an event is near maturation, they report on the outcome. If they report wrongly or they do not report at all they risk losing 20% of their REP (native Augur tokens). The value of augur is directly proportional to the quality of the reporters. Why? Because if a lot of the reporters are dishonest, then no one will want to use augur, which will significantly decrease the demand. This forces all the reporters to remain honest.
- The Wagerers: They bet on the future of the markets based on the reports by the reporters.
- The Market Creators: They will be creating the markets for the reporters to report on and earn market fees as a result.
The Reporting Period
The reporting is done in two phases. Within the first month of the completion of the event, the reporters submit their report to the network, which is tightly secured and kept away from the public. A month later, the second phase happens where the reports are shown in an open ledger, which is free for all to see. When that is done, we reach a final consensus.
Aftermath Of The Consensus
- The wagerers get their appropriate reward for putting their bets.
- The reporters who reported honestly get fees from the wagerers.
- The reporters who didn’t report correctly get 20% of their REP deducted and that, in turn, goes to the reporters who reported honestly and accurately.
Rootstock (RSK) is a smart contract platform that is connected to Bitcoin´s blockchain through sidechain technology. Rootstock allows you to create applications compatible with ethereum (the web3/EVM/Solidity model) while still enjoying the security provided by Bitcoin’s blockchain. At its very core, Rootstock is a combination of:
- A Turing-complete resource-accounted deterministic virtual machine (for smart contracts) is compatible with the Ethereum’s EVM.
- A two-way pegged bitcoin sidechain (for BTC denominated trade) based on a strong federation.
- A SHA256D merge-mining consensus protocol (for consensus security relying on Bitcoin’s miners) with 30-seconds block interval. (for fast payments).
Rootstock will also be using its tech stack – the Rootstock Infrastructure Framework Open Standard (RIFOS) to help build a healthy economic system on top of Bitcoin, sort of like a decentralized AWS. It’ll facilitate the use of blockchain technology by making it as simple for everyone as possible. Keep in mind the following features when it comes to RIFOS:
- As long as a product is compatible with the underlying protocols, developers can seamlessly integrate it within the RIFOS ecosystem.
- All the individual components of RIFOS have been designed to maximize the potential benefits for those who want to offer their infrastructure services within the protocol’s ecosystem.
- All the components are protected by the security provided by the bitcoin Network.
- Its protocols will include mechanisms to trigger network effects and economies of scale.
- Most of the services running in RIFOS will be consumed utilizing a single token (RIF).
RIF Gateways brief overview
RIF Gateways provides a network of oracles to enable secure and tamper-proof interactions with the external world. It proposes an interface layer that unifies access to oracle services and cross-chain integrations, providing blockchains with an implementation-agnostic protocol for both internal and external data consumption. Here are some points about RIF Gateways to keep in mind:
- Builds bridges between blockchains.
- It allows data providers and consumers to engage in secure and standardized data transfers.
- Supports a wide range of data consumption, subscription, and payment models.
- Data services: To consume external data from the blockchain.
- Triggers service: Consuming external data from within the blockchain.
- Scheduler service: Request future execution of a blockchain transaction.
#1 Data Services
A data service provides a specific kind of external-world data. External data can come from a single data source or a network of multiple data sources. This is how it works:
- The creator and offeror of a data service is called “Data Service Provider.”
- Consumers can choose among different types of data services and then interact with the corresponding Data Service Provider’s smart contract for getting the external data.
- The Service Provider must implement the Data Service interfaces in their smart contracts.
- The Provider must periodically update their data since their consumer may need that data that’s latest or the one that was published a little time back.
How does the interaction between the Provider and Consumer works?
There are two methods that a consumer can use to consume the Provider’s data – a direct pull model or a subscription service.
Consumer pays for the data on a per-query basis. The requested data is taken directly from the provider. This is a more expensive and slower model.
A consumer pays a fixed price for access. Serving a single piece of data to multiple customers allows the Service Provider to split the cost of fetching the external-world data among all the subscribers. RIF provides two subscription models:
- On-demand: Consumer asks the Provider for the value on an as-needed basis, as long as the subscription is valid.
- Push: Provider pushes the new data to the subscribers periodically.
#2 Trigger Services
A trigger service allows the Provider to procure information from within the blockchain and give it to the consumer for a price. The consumer can build their own notification solution on the API provided by the Provider. The features of the Trigger services are as follows.
- Each Trigger Provider should be associated with a unique domain name. This ensures ease of user accessibility.
- Providers must comply with a predefined interface that has been designed to be consumed by third-party applications.
- Consumers have the freedom to choose between a single Provider or subscribe to a set of Providers.
The Provider can offer a notification service about certain smart contracts or events within the blockchain. He does so by notifying a fixed set of events emitted by the contract being observed.
The consumer can also build a trigger specifically for their own needs. They must specify to the Provider the source of the events they want to be notified about, eg. the smart contract address.
- Even a non-technical-user to create their own notification service.
- To trigger some action, the Provider allows consumers to specify which action is executed once a matching event is received.
- Consumers have the freedom to set the list of events which will be notified by the Trigger Provider.
How does the interaction between the Provider and Consumer works?
The trigger service offers the pull and subscription models
The consumer specifically requests a notification about one particular event.
As with Data Services, a consumer pays a predefined price for the service. However, triggers only have the push subscription model.
#3 Transaction scheduling services
The transaction scheduling service is a decentralized solution that allows a customer to program future executions of on-chain transactions. As with Data Services and Trigger Services, new scheduling service providers can join by registering a new scheduler service that will be discovered through the RIF Marketplace. Consumers may be internal/on-chain or external/off-chain.
How does the interaction between the Provider and Consumer works?
The scheduler service can also offer pull and subscription models.
The consumer pays the amount required after he requests a single transaction schedule for a delegated execution. The execution can be scheduled for a specific time and a given “execution window.”
Consumers can subscribe to delegate the execution of a specific function recurrently. The consumer pays a negotiated price for executing a function recurrently. RIF Scheduler Services protocol proposes just has the push subscription mode for delegating a repetitive execution.
Get started today
Already have an account? Sign In