Blockchain Oracles Tutorial & RIF Gateways Integration with Chainlink
Introduction
Scalability and interoperability—two of the biggest challenges that the blockchain community is presently facing. In a broader context, these are also among the greatest hindrances to large scale mainstream adoption of this emerging technology. Consequently, there have been significant efforts among innovators, developers, and almost every other stakeholder in this domain to conceive of viable solutions to these problems. And in fact, there have been several positive or at least promising outcomes already.
With Ethereum’s advent in 2015, smart contracts have become a reality, widening the scope for interoperable, blockchain-based solutions through dApps. In doing so, the platform has become one of the pillars of a truly decentralized world that extends much beyond P2P finance. Taking a cue, innovators such as RSK have further diversified the space by bringing smart contracts onto the Bitcoin blockchain.
In essence, smart contracts have emerged as a cornerstone of decentralized ecosystems. After all, it is ultimately the smart contracts that actually replace the “trusted intermediaries” of centralized systems. However, despite their significance, smart contracts have certain limitations in and of themselves. The most pertinent among these is the need for reliable data inputs as triggers which often have to come from off-chain sources if the full potential is to be realized.
Over time, off-chain interactions have become a classic problem for the blockchain community to which oracles have emerged as a solution. In turn, they also represent a way of imparting the much-needed scalability and interoperability for blockchains and other decentralized ecosystems. In essence, oracles work much in the same way as their namesake from ancient Greece. Having said that, this guide takes a deep dive into oracles, outlining in the process RSK’s approach to the messengers of the blockchain world.
What is an Oracle?
To define oracles, we must begin at smart contracts. Simply put, they are code blocks that automate processes on a blockchain network based on certain pre-defined conditions. For instance, transfer X amount to B if M happens. While in centralized systems overseers facilitate this transaction, in blockchain ecosystems a cryptographic smart contract performs the role. Thus, it is understandable that smart contracts require data inputs that prove the occurrence of the event.
Blockchain oracles are third-party systems that feed off-chain data into on-chain smart contracts. In doing so, they act as the much-needed link between the blockchain and the external world. In fact, smart contracts have a very limited scope in the absence of oracles. Oracles act as a layer of the blockchain ecosystem that retrieves, verifies, and relates external data for on-chain systems and vice-versa. It’s important to note that oracles are not data sources, but rather a kind of gateway. However, all of this makes little sense unless we understand why external (off-chain) data is at all necessary in this context.
The Need to Bridge On-Chain and Off-Chain Data
As such, individual blockchains are cut off from the external (real) world, in the sense that they have no inherent way of interacting with data from the latter. Similarly, separate blockchains also cannot interact with each other without using bridges. In turn, this leads to a resource constraint and can be seen as the crux of the technology’s interoperability concerns.
Imagine that persons A and B make a bet of 10 BTC, each paying 5 BTC. If team M wins the next soccer match, A gets the entire amount. If they lose, then B wins and gets the money. As digital natives, they decide to minimize the “trust” involved and lock up the amount on a smart contract. Depending on the result, the smart contract will automatically send the amount to A or B’s wallet.
Now, for this to happen the smart contract would need data from the real world about who actually won the match. Obviously, A and B would be using one of the existing blockchains to deploy their smart contract as it would be too cumbersome to create a whole new, specific blockchain just for this purpose. Even if they do, the actual event of the soccer match would still be occurring off-chain—that is, in the real, physical world.
This is just one instance of why or how a blockchain might require external data which is almost impossible to generate on-chain at times. Insurance contracts, trading contracts, DeFi lending/borrowing systems might have similar requirements in this regard.
In a similar way, off-chain systems such as the gaming industry, domain naming services, payment services, and so on, may also require data generated on-chain. Furthermore, as blockchain increasingly becomes a software platform, the need for time-related functionalities grows. Again, the time of the day, month, or year is an off-chain event (entity).
Oracles as a Solution for Deterministic Smart Contract Outputs
“Deterministic” —a term that is simpler than it sounds. When we say that smart contracts need to be deterministic, we simply mean that every user (here, node) must get the exact same return for a given query. That is, if you and your friend raise a query, say, for the price of BTC, both must get the exact same value for every search instance (in this case the value could change over time, but that’s understandable). Furthermore, in blockchain’s context being deterministic also means that the events occur in a particular, sequential order.
This becomes all the more crucial when the outcomes depend on other factors, over and above the data input—time, temperature, location, and so on. When this happens, smart contracts also become highly susceptible to manipulation in the absence of proper solutions.
One of the ways to ensure deterministic outcomes is to have unique query IDs for specific inputs. In the context of blockchains, however, these cannot rely upon single-point sources of trusted information. As goes the cliché, a system is as decentralized as its least decentralized element.
Thus, if the method for acquiring off-chain data is centralized, the system’s holistic decentralization is compromised. For instance, the source could falter or have downtime, or its owner could deliberately manipulate the data in question. Oracles intend to solve this issue by serving as a secure, tamper-proof, and trust-minimized method of ensuring deterministic smart contract executions. In doing so, they make blockchains interoperable with existing off-chain systems, as well as scalable.
Types of Oracles
So much for what oracles are and why we need them. Now, let us look at the various kinds of oracles. Some of these are already available and in use, while others are somewhat rare as of now.
In a broad sense, oracles are mainly divisible on the basis of three parameters:
- Source— whether software or hardware.
- Data movement— whether inbound or outbound.
- Degree of trust— whether centralized or decentralized.
Software Oracles
Under this category, the data originates from online sources—databases, websites, servers, and so on. Since they are associated with the internet, software oracles have access to a huge data pool which is also generated in real-time. In fact, this type of oracle is presently also the most common. Exchange rates, prices of currencies or other assets, airlines or other schedules are some of the data types that software oracles use.
Hardware Oracles
This kind of oracles can establish actual connections between smart contracts and the real world with the help of hardware sensors. These sensors could be anything ranging from barcode to biometric scanners or any other kind of analog-to-digital sensor.
In effect, hardware oracles create digital copies of real-world events that the on-chain smart contracts can interpret and act upon. Among several others, the logistics and supply chain industry could be a major user of hardware oracles. For instance, upon dispatching a product from the warehouse, the seller could feed the relevant data onto the blockchain and trigger a smart contract in the process.
Inbound & Outbound Oracles
Definition-wise, these are rather self-explanatory. While inbound oracles bring data from external sources onto the blockchain, outbound oracles transmit data in the opposite direction. For instance, in the case of a smart contract that requires the day’s temperature, you would use an inbound oracle. On the other hand, you would use an outbound oracle to trigger a certificate generating platform that uses data from on-chain, self-sovereign identities.
Centralized & Decentralized Oracles
As mentioned earlier, oracles are third-party systems, meaning that they exist independently of the given blockchain. Consequently, their ownership and/or point of control exists outside the blockchain’s ecosystem, as does their source of information.
In this regard, oracles may be centralized or decentralized. A single entity controls a centralized oracle and is the only provider of the data. Most of the common drawbacks of centralized systems—monopoly, single point of failure, risk of manipulation, and so on—also apply to this kind of oracles. Furthermore, they also raise pertinent security concerns for the smart contract using them.
On the other hand, a decentralized oracle works in ways similar to public blockchains. Instead of relying upon a single point of truth, in this case, the smart contract interacts with a distributed network of oracles. In doing so, they also employ certain aggregating protocols to validate data. At times, complete blockchains could also serve as decentralized oracles for other blockchains.
Contract-specific and Human Oracles
As the name suggests, contract-specific oracles are designed for a particular smart contract only and serve one or more specific purposes. For obvious reasons, this is the most unsustainable and rare kind of oracle.
Another type to be mentioned is Human Oracles—individuals with specialized and valid information in a given domain. Although the individual can cryptographically verify their identity, the idea itself defeats the purpose of decentralization by all means.
The Oracle Problem
By now, we have a working idea of what oracles are, how they work, and why we need them. Despite the oracle’s pivotal role in blockchain ecosystems or probably because of it, the community is still facing some major challenges in relation to oracles.
First, there’s concern regarding the efficiency and reliability of the oracle itself. Any bug or vulnerability in the oracle’s code can compromise the security of the underlying smart contract and also the associated blockchain.
Second, the blockchain’s security protocols also don’t apply to the oracles as they exist off-chain. Moreover, in the case of a trust-dispute between third-parties and the smart contract, there is usually no scope for a resolution.
Third, there’s a constant threat of Man-in-the-Middle attacks. In these, a malicious external agent intervenes into the data flow and corrupts it in the process.
The Challenge of User-Friendliness
In the context of the challenges associated with oracles, the lacking ease-of-access demands a special mention. However, this is a problem with the present state of the industry and not the technology in itself.
When it comes to the large-scale use of oracles, affordability plays a major role. Users need to be able to browse available options, educate themselves regarding the specifications, compare between options, and also have access to reviews. Given the scarcity of such platforms, users need to have in-depth and technical knowledge of which oracle to use for which purpose.
Moreover, presently it’s the user’s responsibility to decide which data source is reliable and which isn’t. Added to that, is the need to individually determine the cost for interacting with each specific off-chain data set. Similar problems exist in the case of outbound oracles in which external systems use on-chain data.
As a whole, the problem stems from the need for unified data service and oracle marketplaces. In turn, the associated difficulties are often highly discouraging for those who wish or need on-chain-off-chain interactions for their systems. From a broader perspective, this is a major hindrance to mainstreaming the usage of blockchain-based solutions.
Working with a thorough realization of the problems affecting the space, IOV labs has innovated the RIF Gateways platform.
RIF Gateways — IOV Lab’s Solution for Interoperable Blockchains
Powered by RSK, RIF Gateways is the unified, user-friendly platform that significantly eases end-user oracle usage. In essence, RIF Gateways is to blockchain users what an eCommerce platform is to day-to-day shoppers, in the sense that it offers a wide-ranging toolkit of interoperability solutions.
The marketplace offers a unified interface layer that end-users can use seamlessly to gain access to a wide range of oracle services and cross-chain integrations. In doing so, IOV Labs is solving one of the biggest pain points relating to oracles and smart contracts. While linking blockchains to the external world as well as other blockchains, these implementation-agnostic protocols enable both internal and external data consumptions. They foster standardized yet decentralized data transfers, thus widening the scope for smart contract deployments manifold.
In general, the services with which users can interact on the RIF marketplace fall under three categories—data services, trigger services and scheduler services.
Data Services
This represents a network of data services, each of which relays some kind of data from the external world. Presently, several kinds of data services exist and can be differentiated on the basis of how they resolve a query, their data sources, their degree of decentralization, the nature of their ownership and finally that method of paying for the accessed data.
On the RIF marketplace, end-users can browse the available options for data services, interacting with the service provider’s (usually creators) smart contract. Simplifying the process further, the smart contracts are hosted under human-readable domains. There are two consumptions models for users to interact with data services—the pull model and the subscription model.
Pull Model
Under this, both payment and data retrieval occurs on a per-query basis. Upon request, the users’ systems are directly fed with the latest data, thus eliminating the need to use caches. However, this model is not only more expensive but also slower than the other alternatives as it involves queries and callbacks.
Subscription Model
Subscribers (end-users) pay a fixed price for data access, while the service provider may cache and periodically update the required data. From the user’s perspective, this model is more accessible and also cheaper.
From the provider’s perspective, it allows them to distribute the costs of fetching the data among multiple users by serving all of them with a single piece of data. However, the end-user-prices vary based on the frequency of resolutions required.
Trigger Services
While data services related to inbound oracles, these comprise of outbound oracles that feed single-source or multi-source data from the blockchain to off-chain systems. Here, the data-fetching is implemented off-chain. Furthermore, users can build their custom notification solutions on top of these trigger services. Since the service providers are required to have a pre-defined interface for their offerings, end-users can browse and/or access them using an explorer app and a human-readable domain.
Consumers of trigger services are also safeguarded by SLAs and can opt for either a pull model or a subscription model. All of these work in the same way as they do with data services. Broadly, triggers available on the RIF marketplace differ in terms of how they consume/process the on-chain information and their degree of decentralization. However, in a more specific sense, users can interact with two major types of triggers on the platform—pre-defined and custom.
Pre-defined Triggers
Often related to particular smart contracts or virtual machines, these offer only a fixed set of notifications as defined by the provider at the outset. However, these might offer the users with the ability to apply filters as per their needs.
Custom Triggers
In essence, these work like libraries which the user can use to develop their own notification systems by acquiring the building blocks from the provider. Simple interfaces that even non-technical users can use easily are among the greatest upsides of these services on the RIF marketplace.
Consumers and providers can have P2P interactions to decide the price unless it is pre-defined. Moreover, as highly customizable solutions, users of these triggers can specify the data source, the list of events, as well as executable action upon the event’s occurrence.
Scheduling Services
These solutions enable users to schedule blockchain transactions for a future point based on the occurrence of certain events. For instance, transfer X value to B on, say, 17th August 2025. Similar to data and trigger services, users can consume these services on a pull or subscription basis. Disputes are generated and resolved in similar ways as well. However, the fact remains that these transactions still require users to pay a certain gas price, although they are scheduled for the future. After all, present or future, these are ultimately transactions occurring on the blockchain network and all of the regular principles apply.
Expanding the Scope with Chainlink Integrations
If there’s a “leader” in the oracle space, it’s Chainlink. It is not only the most reliable blockchain oracle protocol available but also the most widely used and trusted. Now, by integrating Chainlink Oracles at the infrastructure-level of the RSK platform, IOV Labs has widened the avenues—for both of the companies as well as their users.
As such, Chainlink’s solutions are optimally decentralized. Thus, this integration offers bitcoiners on RSK’s network the opportunity to leverage Ethereum-based DeFi solutions. In other words, Ethereum’s collaborativeness is now compatible with Bitcoin’s security. This has long-term implications not just for oracles but for decentralized systems as a whole, while the Chainlink protocol’s modularity ensured a short production cycle for the integration.
Among other things, the integration bridges RSK to Ethereum and enables users to seamlessly transfer their LINK tokens between the two chains. Apart from enhancing the RSK network’s value, this gives Chainlink nodes access to the much wider and diverse marketplace for the oracle solutions.
Summing Up
To compete with traditional payment processors and to be relevant for mainstream usage, blockchains need to be interoperable and also scalable. As a foundational element of decentralized ecosystems, smart contracts play a major role on this regard. However, on-chain smart contracts cannot directly interact with off-chain data—that is, data from the external world.
In the absence of this ability, smart contracts have a rather limited scope and do not adequately serve the purpose of fostering interoperability. Thus, enter oracles—third-party solutions that feed external data to on-chain smart contracts (or vice-versa). Acting as the missing link between blockchains and the external world, oracles act as messengers who enable seamless on-chain and off-chain interactions bidirectionally.
However, despite their pivotal role, most of the available oracle solutions are extremely difficult from the common users’ perspective. Realizing this, IOV Labs has innovated RIF Gateways as a part of the holistic RSK smart contract platform. This acts as a unified, user-friendly, transparent, and decentralized interface through which end-users can easily interact with a whole network of oracles. That too, with little or no technical understanding.
Lastly, by integrating Chainlink’s protocol—a leading provider of oracle solutions—IOV Labs has taken another giant step towards interoperable blockchains. This Ethereum-Bitcoin bridge is also a groundbreaking instance of how collaborations and cross-chain interactions could make blockchain technology more adoptable for real-world use cases.