Oracle: The Bridge Connecting the Crypto World and the Real World

Author: IOBC Capital

Blockchain is a system that operates independently of the real world. The data in the crypto world is generated on-chain and continues to be used on-chain. Data from the off-chain world cannot be directly transmitted to the blockchain.

However, in certain application scenarios of smart contracts, external world data is needed, such as in some DeFi contracts where the prices of external assets are required as parameters for the operation of the smart contract. In these scenarios, oracles are needed. An oracle is a tool that transmits off-chain data to on-chain smart contracts and can also transfer on-chain data to the off-chain world.

Oracles serve as a bridge linking on-chain smart contracts and the off-chain world, providing a way for smart contracts to obtain off-chain data. Without oracles, smart contracts can only use data generated on-chain and cannot utilize external data.

As interactions between various protocols increase, the interdependence of data among them also gradually strengthens, making oracles an important infrastructure in the blockchain world.

On the surface, oracles solve the problem of transmitting off-chain data to on-chain. However, in essence, this is not a difficult process; the real challenge is how to ensure that the data transmitted to the blockchain is genuinely trustworthy and reliable, which is the core issue that oracles aim to address.

In other words, oracles fundamentally address the issue of trust. Oracles need to design their technology and mechanisms in such a way that the data they provide can be accepted and trusted by data consumers.

Types of Oracles

As mentioned earlier, establishing trust in the data provided is the top priority for oracles.

Based on the different mechanisms of trust generation, oracles can be categorized into several types:

1. Centralized Oracles

2. Decentralized Oracles

3. Consortium Oracles

Centralized Oracles

Centralized oracles provide data for smart contracts from a single centralized entity. In this case, data consumers need to trust that this oracle will not deceive them, so the centralized oracle must prove itself to be trustworthy.

Centralized oracles have two implementation mechanisms:

• The first is to prove that it operates in a trusted execution environment through authenticity proof mechanisms such as algorithms, ensuring that the data provided is genuine and unaltered at a certain point in time. Data users do not need to trust the centralized entity itself, but only need to trust the technology and mechanisms used by the centralized entity.
• The second is an official oracle provided by the data source. These data sources are usually reliable and credible institutions in the off-chain world, possessing good credit and reputation, and data users only need to trust the institution itself. This model is somewhat similar to traditional internet services, where users utilize services provided by institutions and fully trust these service providers.

Centralized oracles have their own advantages and disadvantages.

Since data is provided by a single entity, user trust in the entity determines the oracle's credibility. A single data source cannot avoid single points of failure and cannot constrain malicious behavior, making security difficult to guarantee.

Additionally, centralized oracles often find it challenging to connect to other oracles, thus limiting the range of data they can provide.
However, because there is no need for coordination and negotiation among multiple nodes, they save a lot of time and improve efficiency, while also eliminating the need to pay for a multi-node network, resulting in lower usage costs.

Decentralized Oracles

Decentralized oracles align with the decentralized design spirit of blockchain, ensuring data credibility through mechanism design. In decentralized oracles, numerous nodes form a distributed node network that collaborates to provide data, competing and constraining each other, thereby reducing the likelihood of malicious behavior through economic models and enhancing the fault tolerance of the entire system.

Since multiple nodes need to work together, the scale of the decentralized oracle's node network affects the reliability of the data provided. Larger networks provide data with higher credibility, so systems typically offer economic incentives to encourage more nodes to participate.

Nodes participating in providing services are usually required to stake a portion of tokens (generally the project's own tokens) when providing data. If the system detects malicious behavior from a node, the staked tokens will be confiscated.

When designing decentralized oracles, several issues need to be considered:

• 1. The collusion problem among nodes; how to respond if multiple nodes collude to act maliciously;
• 2. Data privacy; how to ensure the confidentiality of data when nodes are open to data transmission and queries;
• 3. Timeliness of data acquisition; how to reduce the coordination and confirmation time between multiple nodes;
• 4. The issue of nodes copying data from other nodes; how to prevent nodes from directly obtaining data from other nodes instead of extracting it from the data source;

Decentralized node networks can avoid the single point of failure of centralized oracles, but correspondingly, using decentralized oracles can be more expensive due to the need to pay service fees to multiple nodes.

Consortium Oracles

Consortium oracles are a special form of decentralized oracles. The node network consists not only of ordinary nodes but also of designated trusted institutions as nodes. For example, the v2 version of MakerDAO's oracle includes institutions like dYdX and 0x as nodes.

The trust in consortium oracles is more complex compared to the previous two types, as it includes trust in reputable industry institutions as nodes, trust in the network's checks and balances, and trust in the mechanisms by which the oracle project selects nodes. Data consumers need to trust that all these parties will not choose to engage in actions that could harm their own reputations due to self-interest.

The composition of this node network has a certain degree of centralized characteristics, but as a cost-effective trade-off, it is a good choice in the early stages of industry development. However, this centralized trust mechanism may struggle to support the demands of high-value smart contracts.

From the above description, it is not difficult to see the issues faced by consortium oracles:

• 1. The confidentiality of trusted node identities may affect whether nodes can be extorted or bribed, thus impacting the network's secure operation;
• 2. Whether the data provided by trusted nodes has significant self-interest correlation; after all, if it involves self-interest, it is difficult to avoid the possibility of data being maliciously manipulated.

Representative Projects in the Oracle Space

The following will briefly introduce the leading project in the oracle space, Chainlink, and the representative project in NFT oracles, Banksea.

Chainlink

The working mechanism of oracles can be summarized as follows: a user smart contract (User-SC Contract) that requires data requests data from the oracle contract, which then retrieves data from external data source APIs, processes it, and returns a weighted result to the user smart contract.

There are several main roles in this process: the data consumer (user smart contract), the oracle, and the off-chain data source.

Chainlink is a decentralized oracle. In its distributed node network, multiple nodes, upon receiving data requests, will request data from multiple external data sources. Each node sends the collected data to the on-chain oracle contract for data aggregation, which audits the collected data, removes outliers, and provides an average value to the data consumer.

Chainlink has three main smart contracts: the reputation contract, the order matching contract, and the aggregation contract.

The reputation contract records the historical performance of oracle nodes providing services; the order matching contract matches suitable node network solutions for data consumers through Service Level Agreements (SLA), considering factors such as node reputation, price, and the number of nodes in the network; the aggregation contract processes the data provided by oracle nodes and delivers the final result data.

Users can filter and combine oracle node service providers that meet their needs by selecting parameters such as price level, network size, and node reputation, and determine the SLA proposal, which will be submitted to the order matching contract. The selected service provider nodes then choose whether to bid, and when bidding, they must attach a deposit (a certain amount of LINK tokens) to avoid malicious behavior. If malicious behavior occurs, the deposit will be forfeited. Once the required number of bidding nodes is reached, no new bids will be accepted, and the final service provider will be selected from the previously bidding nodes. The deposits of unselected nodes will be refunded.

The selected nodes will collect data off-chain and ultimately submit the data received from multiple data sources to the aggregation contract, which will process the data through various methods, such as removing obviously deviating data and performing weighted calculations. User smart contracts use LINK tokens to pay fees to the service provider nodes that provide data.

During the service provision process, the reputation contract records the performance of the nodes, including: the total number of requests assigned (both completed and uncompleted responses); the total number of completed requests and the success rate; the total number of accepted requests, the number of requests accepted by the contract, and the accuracy rate; average response time; staked amount, penalty amounts, etc.

Banksea

As an important infrastructure in the NFTFi industry, NFT oracles provide references for the valuation and pricing of NFTs in the market, supporting the development of subsequent financial services.

A typical application scenario is NFT collateralized lending. With the data from NFT oracles, lending service providers can determine the amount that borrowers can borrow and decide whether the collateralized NFTs need to be liquidated when market prices change, to mitigate losses in a timely manner.

According to Banksea's official white paper, Banksea is a decentralized NFT oracle that integrates functions such as NFT data analysis, NFT valuation, and comprehensive risk assessment of NFTs.

The Banksea NFT oracle consists of a data aggregator, AI analysis, and a user interface. The data aggregator collects and processes raw data, including on-chain data, trading activities in NFT marketplaces, user opinions on social media, etc.; AI analysis generates NFT valuations, 24-hour average prices, floor prices, risk assessments, and other data for smart contracts; the user interface (Oracle Contract / Banksea API) can output these valuations externally.

Conclusion

When oracles were first introduced, they did not receive much attention due to the lack of application scenarios.

However, as the application scenarios for smart contracts gradually increase and various DeFi and NFTFi applications emerge, the blockchain increasingly needs to interact with the off-chain world, and oracles are gradually becoming an important infrastructure in the blockchain world.

While centralized oracles are low-cost and efficient, their design contradicts the spirit of decentralization, and they will always face doubts about reliability and security. In contrast, decentralized oracles, while slightly less efficient, can effectively avoid the risks of single points of failure, and the competition and checks among network nodes can also reduce malicious behavior.

Ultimately, the issues that oracles need to address are still those of trust and security. Decentralization is one direction for solving these problems, and whether other directions and products will emerge in the future remains to be seen.