Get Social

What is an Oracle

What does Oracle mean?

Oracles are data feeds that connect a blockchain, such as Ethereum (ETH), to off-chain, real-world information so that smart contracts can query data. For instance, prediction market decentralized applications utilize oracles to settle payments based on events.

In other terms, an oracle connects the blockchain to the physical world. They function as on-chain APIs that can be queried to obtain data for your smart contracts – The key term here is “Big Data”. This could include everything from price data to weather forecasts. Oracles can also “send” data into the real world.

Imagine that a farmer has a contract with an insurance company. This contract compensates him in case of crop failure. The contract is also stored as a smart contract on the blockchain. For example, such a crop loss could result from a prolonged dry period. For the smart contract to now understand a prolonged dry period, it needs a link to the real world, in this case, to a weather data provider like AccuWeather. This link, in this case, is an Oracle, such as API3, which connects the two worlds, automates the process, and eliminates any possible ambiguities regarding contract fulfillment. It is evident when the insurance company has to compensate the farmer and when it does not.

“We look forward to seeing how hybrid smart contracts using AccuWeather data will create value for farmers, businesses, and people around the world.”

– Kurt Fulepp, Global Chief Product Officer, AccuWeather

Why are Oracles necessary?

With a blockchain like Ethereum, every node in the network must replay every transaction and produce the same result with absolute certainty. APIs introduce possibly changeable data. If you used a price API to deliver ETH based on an agreed-upon $USD value, the query would return a different answer daily. In addition, the API could be compromised or deprecated. If this were to occur, network nodes would be unable to agree on Ethereum’s present state, breaking consensus. Oracles address this issue by publishing the data on the blockchain. Therefore, each node that replies to the transaction will use the same immutable data that is publicly available.

The Oracle Problem

The oracle problem appears to be a paradox. Most smart contracts require off-chain data to be executed when they are created on Ethereum as a decentralized system. Ethereum cannot obtain information from the real world. It requires an oracle, which is only one source of information. Because decentralized systems are only as good as their weakest link, connecting an oracle with a single point of failure to the blockchain may result in a complete loss of decentralization. Oracles are attempting to address this issue by implementing various consensus protocols or ensuring that data comes directly from a source, such as the Blockchain Presence with its Sender Authentication model. As blockchain infrastructure improves, more innovations and solutions emerge faster than ever before.

Security

Oracle’s security is only as strong as its data source (s). Suppose a decentralized application (dapp) uses Uniswap as an oracle for its ETH/DAI price feed. In that case, an attacker can alter Uniswap‘s price to influence the dapp’s perception of the current price. A system like MakerDAO‘s feed system aggregates price data from multiple external price feeds rather than relying solely on a single source is one example of a method for addressing this issue.

Architecture

Here is a simple example of an Oracle architecture, but additional techniques exist to activate off-chain computing:

Generate a log containing your smart contract event.
An off-chain service has subscribed to these specific logs (often using the JSON-RPC eth subscribe command).
The off-chain service then executes the actions specified in the log.
The off-chain service answers to the smart contract with the requested data in a subsequent transaction.
This is how to obtain data on a 1:1 basis, but to increase security, you may wish to decentralize how you collect off-chain data.

The subsequent stage may be a network of these nodes making calls to various APIs and sources and collecting the data on-chain.

Chainlink Off-Chain Reporting (Chainlink OCR) for example has enhanced this system by having the off-chain oracle network speak with each other, cryptographically sign their responses, aggregate their responses off-chain, and send only one transaction on-chain with the result. Thus, less gas is expended, but the assurance of decentralized data remains, as each node has signed its portion of the transaction, rendering it unchangeable by the transmitting node. If the node does not transmit a transaction, the escalation policy kicks in, and the next node sends the transaction.

Usage

Using services such as Chainlink, you can reference decentralized data on-chain that has already been extracted and collected from the real world. Similar to a public common, but for distributed data. You can even construct your modular oracle networks to obtain any tailored data. In addition, you can do computations off-chain and communicate data to the actual world. Chainlink possesses the necessary infrastructure to:

Receive price feeds for cryptocurrencies in your contract.
Generate verifiable random numbers (useful for gaming). Invoke external APIs – a fresh application is checking wBTC reserves.

Two types of Oracles: Centralized vs. Decentralized

Blockchain oracles are classified based on factors such as information source, direction, and trust level. Many companies and businesses that plan on VCP implementation find it challenging to choose between two types of Oracles. This decision is critical, primarily from an operational standpoint. Let’s look at how the two types of oracles differ.

Centralized Oracles

Oracles that are centralized act as a singular entity that provides data from an external source to a smart contract that operates with security features. These oracles are managed by a single entity and serve as the sole source of information for smart contracts. It suffers from a bottleneck problem, or a single point of failure, because it operates similarly to the traditional financial system, with a single entity responsible for everything. These oracles have a simple architecture and require less infrastructure and maintenance. Although they provide defense against game theory attacks, they are still vulnerable to corruption and attack.

Decentralized Oracles

These types of Oracles do not rely on a single source of truth, which increases the credibility of the information provided to smart contracts. Unlike centralized oracles, these oracles rely on various external sources and strive for trustlessness. It employs the ShellingCoin mechanism, in which all independent sources report data without coordination. However, this mechanism is vulnerable to various issues, such as collusion between parties, signaling, and bribery. Such oracles are ideal for businesses with multiple plans running simultaneously, but they require a higher investment in infrastructure and maintenance.

In general, decentralized oracles are faster operation but are insecure. On the other hand, Centralized oracles are slower but more secure. As a result, many DeFi applications choose to run on centralized oracles, while others run on decentralized oracles.