Finding the Fountain of Trust: Understanding the Principles, Types, Current Status, and Development Directions of Oracles

This article was published on October 9, 2019, on Chain News, discussing: Wu Weilong (Genaro CTO), Li Hua, content organized by: Li Hua

Like any computer system, the work of blockchain is also about processing data.

There are two sources of data: one is already on the blockchain, such as the amount of ETH in an account; the other is not on the blockchain, such as the price of ETH. How does a blockchain system obtain data from outside itself? It can use an oracle: when a contract needs some off-chain data, it asks the oracle, which then retrieves the data off-chain and provides it to the contract.

From this perspective, oracles are very important. Without them, the development of blockchain would be limited to the small amount of asset data available on-chain, which clearly does not meet our expectations. However, important things are not necessarily the key factors that influence system development. For example, oxygen may be the most important thing for humans, but it hardly constitutes a problem that troubles us.

Let’s compare the internet with blockchain. It is evident that the data sources of the internet are also almost exclusively "off the net" (corresponding to off-chain). It also has the issue of "going online" (corresponding to going on-chain) for data, but why hasn’t it encountered the oracle problem?

The reason is not that applications on the internet can read data from off the net, while applications on the blockchain must use oracles to read consistent off-chain data due to consensus requirements—actually, any on-chain application can easily write its own oracle as an interface for off-chain data. The key issue is whether users trust the data provided by this oracle.

At its root, the reason lies in the fact that the traditional internet is a centralized structure. In such a system, users choose the centralized institution and must trust the data provided by that institution, shifting the trust issue from data to the center. The "going online" of data is completed by centralized servers themselves. Of course, users can also choose not to trust.

In contrast, blockchain is a distributed structure. We hope to create a trustless system, where trust is built on transparent mechanisms and open-source code implementations of those mechanisms. This way, centralized institutions cannot exploit users' trust needs to build monopolistic walls and then "do as they please" within those walls.

The oracle problem manifests itself as follows: putting data on-chain using an oracle is not difficult; simple read and write operations can "feed" off-chain data to on-chain contracts. However, producing trust is quite difficult. Oracles must design their technology and mechanisms to ensure that the data they provide meets users' trust requirements.

Thus, functionally, oracles solve data problems, but essentially, they need to solve trust problems. This is precisely why the internet does not have a "data going online" problem, while blockchain has a "data going on-chain" problem.

As blockchain develops and requires off-chain data to explore and implement more applications, oracles must be able to meet the demand for "trusted data." Therefore, in our discussion of the theme of "blockchain infrastructure," we chose oracles as one of the topics.

1. Design Ideas of Oracles

Once we understand that the core of oracles is to solve trust issues, we can grasp the main differences in design ideas among various oracles, which lie in their "trust production mechanisms."

Based on different sources of trust, the current mainstream oracles can be divided into three categories:

1. Data provided by trusted centers, such as Provable (formerly Oraclize).
2. Data provided by distributed nodes, such as Chainlink.
3. Data provided by trusted alliances, such as the oracle of Maker.

Before introducing the specific implementations of different types of oracles, there are a few points to note, or rather, points worth our consideration and discussion:

• The role of oracles is not to provide "real data," but to provide "trusted data." "Real" is a subjective concept and a difficult concept to evaluate. There may be no tool in the world that can guarantee the output of "real," and it is unrealistic to expect oracles to fulfill such a function. We cannot design a mechanism to ensure reality, but we can design mechanisms to improve trustworthiness. If we require oracles to provide reality, we easily fall into the debate of oracle uselessness and blockchain uselessness, as they indeed cannot meet our demands for reality.
• Different application scenarios have different trust requirements. Not all data needs to be put on-chain under the highest level of trust assurance. This involves the cost of trust and is related to the importance of data credibility, motivations for data falsification, and other dimensions.
• Different application scenarios have different sources/supports of trust. In other words, we cannot assume that trust produced by a certain mechanism is optimal, while trust produced by other mechanisms is poor.

Thus, when we observe oracle projects, important points of focus can be on how they produce trust and whether the trust they provide can meet the needs of the applications they serve.

The design of oracles also involves another important issue: the data source, that is, where the data providers in the oracle obtain their data. This can be divided into two types: one is to obtain data from a single data source, and the other is to obtain data from multiple data sources.

2. Specific Implementations of Oracles

Let’s start with the sources of trust to understand the specific implementations of different types of oracles.

Oracles are an important infrastructure of blockchain, but they are not a "magical" technology. What they do is simply provide off-chain data to on-chain applications. Regardless of the type of oracle, they are merely different implementations of data providers.

We can imagine a small town where there is a large clock displaying the time (data source), and there lives a blind person (blockchain application). The blind person wants to know the time, but he cannot see the clock, so someone has to tell him the time displayed on the clock. This person is the oracle.

1. Data Provided by Trusted Centers

If there are 10 blind people in the town, and time is very important to them, the oracle can become a business. Each time a blind person asks this person for the time, he has to pay him 1 dollar. With 10 blind people, each asking him 10 times a day, he can earn 100 dollars a day.

If this person goes to check the time on the clock and then tells the blind person, we call this method data provided by a trusted center. In this case, the premise for the blind people to choose this person is that they must trust that he will not deceive them, so this person needs to prove that he is trustworthy.

One type of centralized oracle's trust assurance is "proof of authenticity technology," such as Provable. It uses the TLSNotary algorithm, which can provide an unaltered proof for each returned result, meaning it can indicate that the data provided to the contract is the correct data from the data source at a certain point in time.

Town Crier also belongs to this type of oracle. It uses Intel SGX (Software Guard Extensions) architecture to prevent data tampering by running code in a black-box-like environment, providing a hardware-based trust mechanism.

These types of oracles have their own weaknesses, including technical issues, such as the shortcomings of the TLSNotary algorithm; single point of failure issues; data source risk issues, etc. However, they also have advantages such as low cost and high efficiency, and the technology of proof of authenticity is continuously evolving.

Although they are centralized, since these oracles are commercialized, they only do the work of providing data, and the security of the data is directly related to their own development, so their motives for wrongdoing are relatively small.

In addition to oracles that provide trust through technology, there is another type of trusted center oracle: imagine if the town's clock added a time announcement feature? The blind person walks up to the clock, presses a button, and the clock directly tells him the current time.

When a blockchain needs certain data from an authoritative institution (such as a government agency, bank, etc.), having that institution build an oracle to provide data may be a good approach. At this point, what matters is not the technology of the oracle, but whether the data source itself is willing to open an interface. The source of trust is not the design of the oracle, but the institution itself.

This is a way to inherit off-chain trust to on-chain, relying on the trust produced by traditional trust production mechanisms. Although highly centralized, it has positive and significant implications for a considerable period in history, such as in lending and commercial lending scenarios. Remember, blockchain is not meant to negate all other ways of producing trust.

Taking government institutions as an example, it is easy to understand the characteristics of this type of oracle, but this category may also include commercial types of data sources and oracles that serve specific data needs. Such data is often the result of calculations of a large amount of special data, and only specialized institutions have the capability to provide such data results.

2. Data Provided by Distributed Nodes

Oracles aim to solve trust issues. Oracles that provide data from trusted centers prove/guarantee their trustworthiness through technology, while oracles that provide data from distributed nodes ensure their trustworthiness through mechanism design. The latter is often referred to as decentralized oracles or decentralized oracle networks.

Let’s return to the small town. A decentralized oracle network means that everyone in the town can participate in reporting the time. When the blind person asks for the time, these participants/nodes tell a statistician the time they see, and the statistician then tells the blind person the time that most people reported.

It is not difficult to see that the design idea of this type of oracle is consistent with the distributed thinking of blockchain, so it does not add new types of trust to applications on the blockchain; and by not adding new types of trust, the complexity of the situation does not increase. However, this method also has limitations, such as being relatively expensive because it requires payment to many participants; it requires network scale, as the number and quality of participants are related to the credibility of the data.

Chainlink is an example of this type of oracle. As shown in the figure below, distributed oracle nodes/oracle service providers obtain data from decentralized data sources and submit the data to Chainlink's on-chain aggregation contract (which will be changed to off-chain aggregation in the mid-to-long-term strategy to save gas fee costs). This contract calculates the data results through algorithms and sends the results to the blockchain application that requested the data.

In Chainlink, the buyers of oracle services first specify their service levels, and then Chainlink matches them with oracle nodes, including the quality and quantity of nodes.

For example, if the buyer's contract is a $100,000 DeFi market, they may need to choose 5 oracle nodes to form a network; if the contract grows to a $1 million market, they may need to choose 15 oracle nodes. One can think of Chainlink's working method as providing a customized dynamic oracle network based on user needs.

In addition to the aforementioned specialized oracle projects, prediction markets, such as Augur, can also be considered a category of decentralized oracles, as their prediction results can serve as input data for blockchain contracts. Each participant in the prediction is an oracle node, and these participants are also the data sources themselves.

The oracle functionality provided by prediction markets may be irreplaceable by other categories of oracles due to the uniqueness of their data sources, such as not relying on any centralized trust, and being able to provide data that expresses sentiment and knowledge, etc. Prediction markets may have unique oracle application scenarios in the future. However, its weaknesses are also prominent, as it has a high dependency on the number of nodes that make up the oracle network, and its efficiency in providing data is relatively low.

3. Data Provided by Trusted Alliances

If a certain application or category of applications has a high-frequency, high-quality demand for off-chain data, and the oracles available in the market cannot meet the demand, such as insufficient security or poor cost-effectiveness, these applications may need a dedicated oracle that serves their special needs. The approach of providing data by trusted alliances is a suitable design idea for this scenario.

"Data provided by trusted alliances" is a special form of "data provided by distributed nodes," distinguished by the fact that the nodes that make up the oracle network are designated. The V2 version of Maker's oracle may fall into this category, where its nodes include not only anonymous individual price feeders but also designated price feeding institutions such as 0x, dYdX, Set Protocol, and Gnosis.

Compared to the previous two types of oracles, the trust composition of this type of oracle is relatively complex, including trust in the design of the system's mechanisms; trust in the nodes, which largely stems from the stakeholders' identities and the institutional reputation of the nodes themselves; and trust in Maker and its mechanism for selecting nodes.

Trust in the alliance (nodes and node selection mechanisms) has a centralized color, but it is precisely this centralization that can generate "high cost-effectiveness" trust in specific scenarios. Therefore, in practical applications, this type of oracle may be a practical way to put data on-chain, especially in the early stages of blockchain industry development when commercial oracles are not yet mature.

Maker's oracle is led by Maker, but because it meets the demand for trusted data in the DeFi field, some other contracts are also using this oracle. We can also envision a trusted alliance oracle service provided by a third party, which is an oracle network composed of trusted institutions/nodes in the DeFi field, providing professional data services for decentralized finance. If blockchain generates a new category of application scenarios, it may also require the emergence of an alliance-style oracle service composed of trusted nodes from that field.

3. Development Path

As blockchain develops, the demand for off-chain data will become increasingly strong, and the importance of oracles will become more prominent. However, as discussed above, a greater possibility in the oracle field is the emergence of a market with multiple forms coexisting. We can consider that from centralized to alliance-based to decentralized, the granularity of data providers decreases from large to small, and different granularities determine their different attributes, thus determining the service scenarios they are each suitable for.

Although oracles can also be composed of distributed node networks, our perspectives on blockchain and oracles and the standards by which we evaluate them are different: blockchain is exploratory work, more concerned with asking "Is this problem suitable for me to solve?"; while oracles are functional work, more focused on asking "How do I solve this problem?"

Therefore, the design of oracles pursues usability and practicality: it serves the demand, not the vision. The easiest point to understand is that it should pursue cost-effectiveness.

In addition to solving trust issues through technology and mechanisms, the design of oracles also includes many other aspects, such as data privacy issues, the ability to defend against hacking attacks, etc., as these all relate to the usability of the oracle. For this reason, the design of oracles is a comprehensive engineering project involving many fields.

At the end of the article, it must be pointed out that oracles are an important infrastructure of blockchain, but this does not mean that the development of oracles will constrain the development of blockchain. On the contrary, perhaps the state of blockchain development has a greater impact on the development of oracles. Only when on-chain contracts have widespread and urgent demands for off-chain data and can pay for the data will oracles truly and comprehensively develop.