A Zoom on the different types of crypto oracles

Key Information

• Oracle Utility: Oracles enable blockchains to access external data, which is essential for the execution of smart contracts by acting as reliable and secure intermediaries between the on-chain and off-chain worlds.
• Oracle Classification: Oracles are divided based on their system structure, data sourcing methods, data flow direction, and the way they verify data reliability.
• Oracle Trilemma: Oracles must find a balance between data availability, reliability, and incentive compatibility.
• Decentralization Considerations: Oracles can be either centralized or decentralized, each type having its own advantages and disadvantages in terms of speed, security, and data reliability.

---

Introduction and Context on Oracles

By their nature, blockchains are closed and deterministic systems, incapable of connecting directly to the outside world. However, to properly execute smart contracts based on real-world conditions, it is necessary to integrate information from outside the blockchain, such as real-time financial asset prices or weather data.

This is where oracles come in. This technology acts as an intermediary between the blockchain and the external world, collecting data and transmitting it to the blockchain in a secure and reliable manner.

For example, imagine two friends wanting to bet on the outcome of a football match using a smart contract to automate their bet. Since the contract cannot automatically access the match results, an oracle is needed to retrieve this information from various sports sites and communicate it to the smart contract, thus determining the winner and transferring the funds accordingly.

Despite being considered "smart," smart contracts can only execute operations if the initial conditions are met. Thus, they are limited to what happens within the blockchain. For this reason, oracles break the barriers of blockchains by enabling smart contracts to access external data in a reliable and secure manner while maintaining their deterministic nature.

Blockchain oracles first emerged in 2012, very early in the ecosystem’s history. Since then, these protocols have multiplied, as have the technologies used to operate them. In this article, we will explore the different classifications of decentralized oracles, from the structure used to the data retrieval method and their direct use cases.

---

Oracle Classification by System Structure

Oracles can be classified based on the system structure they use to collect and transmit data. At this stage of the technology’s development, three main structures can be distinguished: Immediate-Read, Publish-Subscribe, and Request-Response.

Immediate-Read

Immediate-Read oracles provide essential data for immediate decision-making. They respond to specific requests in real-time, i.e., at the exact moment the information is needed.

Returning to the practical example presented in the introduction—namely, a football match bet between two friends managed by a smart contract—an Immediate-Read decentralized oracle would be particularly suitable.

Indeed, the oracle does not need to constantly connect to the sports result site and continuously update the information. It only needs to retrieve the match result once, at the end of the game. Once this is done, the smart contract can determine the winner and distribute the funds accordingly.

Publish-Subscribe

The Publish-Subscribe model is a structure where the oracle acts as a broadcast channel for information that is likely to change regularly or sporadically. In this system, data is transmitted to the smart contract continuously or at regular intervals, often through an off-chain agent that monitors oracle updates.

Once again, let’s take the example of the two friends who want to make football bets using a smart contract to automate them. Suppose they now want to bet on the number of goals scored by each team over a season. In that case, they will need regular updates on match scores throughout the season.

Thus, a Publish-Subscribe oracle would provide these updated data continuously, allowing the smart contract to track the teams’ performance and manage the bets accordingly.

This type of oracle is also widely used in Decentralized Finance (DeFi), where the prices of digital assets need to be constantly updated. For example, to determine the value of a cryptocurrency during exchanges or liquidations, it is Publish-Subscribe oracles that provide real-time price data to smart contracts.

Request-Response

The Request-Response model is similar to a client-server architecture, where a request is sent by the client (smart contract) and processed by the server (oracle). The data is often stored in an external infrastructure due to its volume or complexity and is transmitted to the smart contract upon request.

In this model, imagine our friends want to bet on the total number of goals scored by teams over the last 10 years. A Request-Response oracle would be used to query external databases that keep archives of sports performances. When the smart contract sends a request for this information, the oracle retrieves the relevant data and transmits it to the smart contract.

This model is particularly useful when the necessary data is too large or complex to be stored directly on the blockchain. For example, applications requiring detailed historical information, complex market analyses, or datasets from multiple sources can benefit from Request-Response oracles.

---

Oracle Classification by Data Flow Direction

As mentioned several times since the beginning of this article, blockchain oracles serve to communicate data between the blockchain and the outside world. However, depending on the direction of this flow, two main categories can be distinguished based on the direction of data flow: "inbound" for incoming data and "outbound" for outgoing data from the blockchain.

Inbound Oracles

Inbound oracles are the most common in the blockchain ecosystem. They introduce data from external sources into the blockchain. This data can include financial information, sports results, weather forecasts, asset prices, or many other types. Inbound oracles are primarily the ones we have discussed since the beginning of this article.

Outbound Oracles

Outbound oracles work in the opposite direction. They take information from the blockchain and transmit it to external systems. Although less common than Inbound oracles, they play a crucial role in certain applications.

For example, if you want to connect a screen in your home to your cryptocurrency wallet to constantly display your daily gains, the price of a cryptocurrency, or alerts on price level breaks, it is important to retrieve data within the blockchain. Outbound oracles are used for this purpose.

---

Oracle Classification by Sourcing Method

Another method of classifying blockchain oracles is the data sourcing method they use. There are several ways to retrieve information before transmitting it to the blockchain and the smart contracts that want to use it.

Software Oracles

Software oracles are the most common and use online data sources to provide information to the blockchain. These sources may include Web APIs, online databases, news sites, and much more. This type of oracle is particularly useful for obtaining up-to-date and dynamic information, such as cryptocurrency prices, exchange rates, sports results, or weather forecasts.

For example, a Software oracle could connect to an API of an online trading platform to obtain the current prices of stocks or currencies. The data is then transmitted to a smart contract that can execute actions based on this information. The main advantage of Software oracles is their ability to access a vast amount of real-time data. However, their dependence on online data sources makes them vulnerable to service outages, data manipulation, and cyber-attacks.

Hardware Oracles

Hardware oracles are much less common, as they use physical devices such as electronic sensors to collect information from the real world. This data is then converted into digital values, making it possible for smart contracts to read and use them.

For example, if an electricity provider wants to monitor its customers' consumption through smart contracts to optimize payments, it will use Hardware oracles connected to its customers’ electricity meters.

These oracles are essential in various applications such as supply chain management, location tracking for delivery services, or weather data collection. Their main advantage is robustness and resistance, as it is much more difficult to corrupt or modify data from a hardware piece than digital data.

Oracle Classification by Data Verification

Finally, the last classification of oracles is the method used to guarantee data accuracy and reliability. The two main ways to differentiate oracles according to this criterion are as follows: using a consensus mechanism or relying on a trusted actor.

Consensus Oracles

Consensus oracles use multiple data sources and employ consensus mechanisms to aggregate and validate the information before transmitting it to the blockchain. The idea is that by leveraging many sources, the risk of manipulation of one source is reduced, thus improving data reliability and accuracy.

For example, a consensus oracle for cryptocurrency prices could collect data from several different exchanges and use a consensus algorithm to determine the median or average price.

Consensus oracles are particularly useful for applications where data accuracy is crucial, such as financial markets or online voting systems. However, this method is often considered more expensive and complex to implement, as it requires coordination between multiple data sources and sophisticated protocols to reach consensus.

Trusted Oracles

Trusted oracles rely on reputable and reliable entities to provide data to the blockchain. Generally, these entities are financial institutions, government bodies, or recognized experts in a specific field. Using trusted oracles can offer additional assurance about data quality and accuracy.

For example, a trusted oracle could be a financial rating agency providing trust scores to users for smart contracts related to lending or borrowing applications. The reliability of this data depends on the reputation and expertise of the agency.

However, trusted oracles introduce an element of centralization, which goes against the decentralization principles of the ecosystem. Additionally, they remain vulnerable to human error, manipulation, and conflicts of interest.

---

What About Oracle Decentralization?

Whenever a technology related to blockchains is mentioned, one recurring question arises: what about decentralization? Obviously, this is a fundamental principle of the ecosystem, whose ambition is to reduce dependence on centralized entities, eliminate single points of failure, and ensure system transparency, security, and resilience.

However, oracle protocols serve applications with such diverse use cases that it is difficult to find a one-size-fits-all formula. This is what we call the "Oracle Trilemma," which we will present in the next section.

The Oracle Trilemma

If you are reading this article, you are probably already familiar with the blockchain trilemma: it is impossible to simultaneously achieve a high level of decentralization, security, and scalability. For oracles, there is a similar issue, which we call the oracle trilemma:

• Data Accuracy: An oracle must ensure that the information provided is reliable and has not been altered so that smart contracts do not make mistakes based on false data. The oracle must ensure that the information comes from the correct source and has not been changed before being used.
• Availability: An oracle must always be ready to provide information to smart contracts so that they can perform their tasks without interruption. There should be no delays or obstacles that prevent smart contracts from making decisions or acting. Information must be available when needed, at all times.
• Incentive Compatibility: Incentive compatibility involves attributability and accountability. Attributability allows correlating external information to its provider, while accountability ties data providers to the information they provide so that they can be rewarded or penalized based on the quality of the information provided.

This trilemma can also extend to the degree of decentralization, the cost of the oracle, the diversity of providers, and other criteria that one might consider more or less important, thus illustrating the trade-offs that oracles might face in their design choices.

Ultimately, to address this issue, and much like other areas of the ecosystem, blockchain oracle protocols are divided into two categories: centralized oracles and decentralized oracles.

Centralized Oracles

Centralized oracles are managed by a single entity or organization, which is responsible for collecting and providing the data. This model is often faster and easier to implement, as it does not involve coordination between multiple parties. However, centralized oracles pose security and trust risks since they depend on a single entity.

Let’s see how they address the oracle trilemma:

• Data Accuracy:
  • Pros: A centralized oracle can ensure better data accuracy because it can directly control and validate the source as well as the integrity of the data before transmitting it to the smart contract. Since it is the sole decision-maker, there can be no disagreements among data providers.
  • Cons: If the centralized oracle is compromised or malicious, it can deliberately provide inaccurate data, and being the only data source, there is no verification or correction mechanism. Thus, the oracle represents a single point of failure due to its centralized nature.
• Availability:
  • Pros: Centralized resource management can guarantee high availability and fast response time for smart contracts.
  • Cons: Being a single point of failure, if a centralized oracle encounters a technical problem or is attacked, data availability can be interrupted.
• Incentive Compatibility:
  • Cons: Centralized oracles often have poorly designed or non-existent incentive mechanisms to ensure that the data provider transmits reliable and unmodified information. One major point of caution is the reputation of the data provider. Although projects prefer to adopt a decentralized oracle, the reputation of the centralized actor can often work in its favor. Once this reputation is broken, the oracle can lose clients overnight.

Decentralized Oracles

In response to the limitations of centralized oracles, decentralized oracles have been developed to enhance data security and reliability. Unlike their centralized counterparts, decentralized oracles are systems that source their data from multiple independent sources that do not communicate with each other. To consolidate all this information, a consensus is implemented by the oracle to transmit unified data to the protocol it interacts with.

Let’s see how they address the oracle trilemma:

• Data Accuracy:
  • Pros: With multiple data sources, a decentralized oracle can aggregate the information, obtain a median price among all data providers, and transmit the valid data. Actors attempting to corrupt the network with false information are financially penalized, thus reducing the risk of attacks. Moreover, corrupting multiple sources is more complex than a single centralized source.
  • Cons: The diversity of sources can lead to disagreements and uncertainty regarding data accuracy. This highlights the importance of establishing an effective consensus while diversifying sources to ensure the proper functioning of the decentralized oracle.
• Availability:
  • Pros: The distributed nature of decentralized oracles increases resilience and minimizes the risk of total failure, as the failure of one provider does not affect the availability of others.
  • Cons: Coordination among different nodes and information providers can lead to latency and affect response availability.
• Incentive Compatibility:
  • Pros: The diversity of participants can lead to healthy competition and strengthen incentives to provide more accurate and reliable data.

Given the concerns and risks associated with trust management, many decentralized finance (DeFi) applications prefer decentralized oracles over centralized ones to transmit data to the blockchain.

The debate still lingers on the true degree of decentralization of oracles. Depending on industry standards and individual perspectives, an oracle can be considered decentralized or not. Thus, as with blockchains, we speak more about degrees of decentralization, which vary according to numerous parameters.

---

Conclusion

As we have understood throughout this article, oracles play a crucial role in the blockchain ecosystem by acting as bridges between the "on-chain" and "off-chain" worlds. By bringing external data to smart contracts, they enable the creation of more sophisticated and advanced decentralized applications.

Over the years, the field of oracles has diversified, and many technologies have emerged. We have proposed a classification based on their system structure, data flow direction, type, sourcing method, and more.

However, one of the main topics of debate is the question of the oracle trilemma. The answer lies in a delicate balance between decentralization, availability, reliability, and incentive compatibility of data.

Decentralized oracles align more closely with blockchain ideals by eliminating single points of failure and offering greater resilience. Conversely, centralized oracles, while faster and often easier to implement, pose significant risks of manipulation and failure.