There are many projects in the blockchain space that require constant interaction with external sources of information. In order to accomplish the transmission of information between different parties, oracles are required. Simply put, oracles are third party services that provide smart contracts with external information. For example, physical products that could be connected to the Internet like a car, a house, a rented bike, etc. would require to send information over to a smart contract on one specific blockchain. Let’s say for instance that you have a lease on a car and you’d want to connect the payments on the lease to a smart contract that would deploy your payment history on a blockchain. Just think about the Internet of Things (IOT) and blockchain technology and you can easily imagine many situations where oracles could be used when renting or paying for using multiple devices.
Extrapolate the idea to APIs and you can have many additional use cases for oracles. For instance, different parties may agree on the outcome of a future event with the conditions locked on a smart contract. In order to execute the smart contract, using a third party API will be required. The API information is not on-chain so an oracle will be required to gather that information and provide the outcome so that the smart contract can execute.
As you can probably imagine from the examples above, oracles have the ability to exponentially expand blockchain technology use cases. Without the possibility of exchanging information beyond on-chain frameworks, smart contracts possibilities would be limited. Now, which are the typical oracles?
1 – Trust Oracles: Is the information centralized or decentralized?
2 – Source Oracles: Is the information originated from hardware or software?
3 – Direction of Information Oracles: Is the information inbound or outbound?
Hardware & Software Oracles
Like the examples above, some smart contracts may require information from external hardware and software sources. For instance, a supply chain process would require a packaging with a sensor (hardware) to reach one specific destination and submit that event to a blockchain. You could also require smart contracts to interact with information within a centralized database (off-chain). These are all examples of different types of oracles.
Centralized & Decentralized Oracles
Smart contracts will require in many situations to interact with information that’s provided from a centralized data hub. Private blockchains could interact directly with smart contracts through interoperability and bridges but many companies using legacy data structures would require an oracle to interact with their databases and APIs. A company using a legacy database would be an example of how centralized oracles would be required to bring that information on-chain when required. Decentralized public blockchains have different companies providing oracle services.
Inbound & Outbound Oracles
Inbound oracles transmit third parties information into a smart contract whereas outbound oracles transmit information from a smart contract to a third party. Using our example at the beginning of this post, you could set one payment address on a blockchain for the lease on a car. The smart contract would check on the payment schedule and unlock the engine of the car if there are no significant delays (outbound oracle). On the contrary, you could require a sensor or device to send specific information to a blockchain in order to trigger a smart contract (inbound oracle).
In order to execute properly, smart contracts need to rely on the information provided by oracles and that’s why the security level of each oracle is of paramount importance. If an oracle can be easily hacked or compromised, all the smart contracts interacting with it would be dealing with corrupted information. This is known as the Oracle problem and it’s one of the challenges of many of the companies in the blockchain space.
How is IOV Labs contributing to Oracles?
RIF Gateways provides a set of interoperability protocols designed 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. It is designed to build bridges between blockchains and allow data providers and consumers to easily engage in secure and standardized data transfers, supporting a wide range of data consumption, subscription, and payments models. For further information, we invite you to visit the whitepaper and stay tuned as we have exciting news in the near future.
