Blockchain Oracles: Their Importance, Types, And Vulnerabilities

Whether you’re just getting started or a seasoned Web3 developer, understanding blockchain oracles is crucial. They’re the backbone that connects your smart contracts to the real world, allowing interactions to go beyond the blockchains. Without oracles, smart contracts are limited to just processing what’s already on-chain, missing out on essential data like price feeds, real-world events, or even web APIs.

In this article, we’ll explore blockchain oracles and their types in detail: why they’re game-changers, their applications, and their potential weak spots. Keep reading till the end! We’ve got some cool bonus waiting for you. 

What’s A Blockchain Oracle, Again?

A blockchain oracle is a service that provides external data to smart contracts, enabling them not only to fetch data from other blockchains but also from the outside or off-chain world: sports events, banking data, and much more. 

The Need For Oracles In Smart Contracts

Smart contracts are inherently isolated and deterministic; they cannot access or retrieve data from external environments without an intermediary. The oracle serves as this intermediary, bridging the gap between off-chain and on-chain data sources.

In other words, oracles are the blockchain’s gateway to the real world. 

Still not sure about oracles’ role? For a better understanding, we provided you with a real-world scenario: 

Let’s assume we have an Ethereum smart contract created to bet on the price of the gold. Both players deposit their bets into the smart contract. What does a smart contract need to have to distribute the prize when the period is over? It needs to have the actual price of the gold. This is when oracles come in handy. Oracles can fetch accurate prices off-chain and deliver them to the blockchain securely and reliably.

How Blockchain Oracles Work 

Users (smart contracts) request and get some information from an external source (any data not stored on the blockchain). According to ethereum.org, here’s an outline of how it works:

1. Data request: User sends a data request. Each request depends on the nature of the application, but generally, it specifies the desired data and sources as well as how to process and aggregate responses into a single value.
2. Data request goes to an oracle contract: The on-chain oracle contract is the powerhouse that receives data requests, passes them on to off-chain oracle nodes, and returns data to smart contracts. Everything is governed by a smart contract, so we cannot overstate the importance of auditing the code to ensure it works as intended.
3. Oracle contract produces a log event that is picked up by an oracle node. This is how the on-chain oracle interacts with the off-chain node. The ‘eth_subscribe’ command is the most common method used in JSON-RPC to create a subscription to certain events on the Ethereum network. A similar method is used in other blockchain networks.
4. Oracle node captures a log event and initiates the off-chain task. The node dispatches an HTTP GET request (or any other API call method) to third-party services. Once data is retrieved, it’s processed, reformatted into a blockchain-compatible format, and then submitted back on-chain via a transaction to the oracle contract. Everything happens off-chain as information transfers are not bound by gas expenses, block dimensions, or other on-chain constraints.

Regarding the distinction between data sources and oracles: oracles are not the sources of data; they are the means by which smart contracts access the data.

Types Of Blockchain Oracles 

Oracles serve different purposes, hence they come in different design and administration patterns. According to the classification by ethereum.org, the most popular design pattern is request-response because it allows smart contracts to query specific information rather than an entire dataset. By contrast, publish-subscribe is useful for fetching dynamic changes, i.e., fiat-to-crypto exchange rates. Another important classification relates to administration. It answers the question: Who controls the oracle: a single entity or multiple peers?  

Based On Network Administration (Trust Model) 

Centralized Oracles:

• Operate under a single entity’s control.
• Efficiently gather off-chain data and update the oracle contract based on requests.
• Prime application emerges when specialized datasets are made available.
• Drawbacks include low correctness guarantees, poor availability, and potentially poor incentive compatibility.

Decentralized Oracles:

• Intend to mitigate centralized oracles’ shortcomings by removing single-point failures.
• Multiple entities in a P2P framework achieve consensus on off-chain data before transferring it on-chain.
• Benefits include high correctness guarantees through multiple strategies, continuous data availability, and good incentive compatibility.

Based On Oracle Design Patterns

Immediate-Read Oracles:

• Provide data immediately upon request.
• Often used for data that is static or changes infrequently.

Publish-Subscribe Oracles:

• Expose a continuously updated “data feed” for smart contracts to access.
• Data is dynamic, necessitating client contracts to monitor for alterations.
• An example is an oracle offering real-time ETH-USD conversion rates.

Request-Response Oracles:

• Permit smart contracts to demand specific data beyond the scope of publish-subscribe oracles.
• Optimal for scenarios where: (1) the complete dataset is extensive for on-chain storage, or (2) users require only data fragments sporadically.
• They encompass an on-chain component receiving data requests, subsequently delegated to an off-chain node for processing.
• Requesting users bear the expense of off-chain data retrieval.
• The invoking contract must allocate funds to offset the gas expenses during the oracle’s response phase.

Interoperability Solutions vs. Oracles

Interoperability solutions range from sidechains to blockchain-agnostic protocols. However, they come with all sorts of challenges, like consistency and requirements for code changes. By contrast, oracles offer compatibility and security across different blockchains. We’ve summarized key points of difference in the table below:

Interoperability Solutions		Oracles
Sidechains	Sidechain logic can be invalidated if the main-chain is compromised. Ensuring consistency is challenging.	Oracles don’t require compatibility between blockchains and have multiple security management ways.
Notaries	Notaries cover the full spectrum of interoperability but centralize trust.	Oracles can address some blockchain vulnerabilities through decentralized solutions.
HTLCS	HTLCs are trustless and adaptable for trades but may lead to asset lockup. Supports only digital asset exchange.	Oracles support both digital and arbitrary data.
BOB	Blockchain engines don’t communicate globally. Some solutions are centralized with necessary transaction fees.	Decentralized Oracles can overcome many of these limitations.
Trusted Relays	Connecting differing blockchain platforms is tough. Minimizing malicious relay services is unclear.	Oracles act as middleware providing off-chain data and have reputation systems.

Blockchain Oracle Use Cases And Applications

Oracles bridge the gap between on-chain and off-chain worlds by retrieving and validating external data for smart contracts.

Financial Data Retrieval for DeFi Applications

Peer-to-peer lending, borrowing, and asset trading in DeFi require real-time financial data, such as exchange rates and capital markets data. For instance, a DeFi lending protocol would need current market prices for assets deposited as collateral.

Oracle Examples:

• Chainlink: Provides tamper-proof inputs, outputs, and computations for advanced smart contracts across blockchains.
• UMA Oracle: Allows smart contracts to receive diverse data for various applications.
• Band Protocol: Connects real-world data and APIs to smart contracts.

Generating Verifiable Randomness for Blockchain Applications

Blockchain-based games or lotteries need unpredictable randomness, a challenge due to the deterministic nature of blockchains.

Oracle Examples: Chainlink VRF and API3 QRNG offer tamper-proof random number generation (RNG), ensuring fairness and unpredictability.

Retrieving Real-World Event Outcomes

Allows smart contracts to respond to real-world events. Decentralized insurance applications might utilize oracles to access accurate weather data or disaster reports.

Oracle Examples:

• Witnet: A decentralized oracle that helps smart contracts respond to real-world events.
• Pyth Network: Publishes real-world financial data on-chain.

Automating Smart Contract Execution

Automates functions within a contract to maintain application functionality. Chainlink’s Keeper Network allows smart contracts to outsource maintenance tasks in a decentralized way.

Major Problem With Oracles: Market Manipulation

Oracles play a pivotal role in the decentralized finance ecosystem, serving as the bridge between external data sources and smart contracts; however, their critical function also makes them a prime target for market manipulation tactics.

Market manipulation is the intentional distortion of price for profit, at the expense of other users. The easier an asset is to trade (its liquidity), the harder it is for someone to mess with its price.

Common Techniques in Market Manipulation:

• Spoofing: Posting numerous trade orders without intending to execute them, often using bots.
• Ramping: Artificially increasing an asset’s market price to drive demand.
• Bear Raid: Deliberate attempts to lower an asset’s market price through heavy sales or short sales.
• Cross-market Manipulation: Trading in one environment to manipulate prices in another, profiting from the price divergence.
• Wash Trading: Simultaneously buying and selling an asset to feign a high trade volume.
• Frontrunning: Trading based on privileged information before the market can respond. In crypto, this is part of Maximum Extractable Value (MEV).

Are Blockchain Oracles Secure?

While many popular oracles are thoroughly vetted and audited, protocols that use them can still mess things up. A notable example is a critical vulnerability in the AaveV3 fallback oracle, where the ‘setAssetPrice’ function lacked essential access control, allowing hackers to set any asset’s price.

At the time of bug discovery (April 2022), Aave was worth nearly $3 billion, so you can imagine the magnitude of a potential hack. The worst-case scenario was averted as third-party researchers spotted the issue and reported it to Aave. These incidents underscore the importance of external code reviews, even when a project uses a battle-tested oracle.

Let’s review the most common attack vectors.

Price Oracle Manipulation

In this type of attack, the objective is to deceive smart contracts by providing false price data. Consider the first hack of Inverse Finance to give you a real-world scenario. A big shout out to the authors of the great REKT article.

A well-planned and executed hack lets a hacker influence the price of the INV token and receive a special offer from the Ethereum-driven lending protocol. The exploiter initially withdrew 901 ETH from Tornado Cash. Once they distributed 1.5 ETH to 241 clean addresses using Disperse, the attacker launched 5 different smart contracts when only one of them was real. Then, they swapped 500 ETH to 1.7k INV via the INV-WETH pair on SushiSwap, significantly changing the price due to low liquidity. Simultaneously, the exploiter began spamming transactions to be the first to enter the next block and get an inflated price from Sushiswap. But why do we mention Inverse Finance here? Unfortunately, the Sushiswap TWAP oracle was used by Inverse Finance through the Keeper Network, which resulted in the price of INV to be drastically increased. Finally, the attacker deposited their 1.7k INV, which should have cost $644k at that time, as collateral and borrowed $15.6M for good.

A lesson here? We shouldn’t rely upon a TWAP oracle generated from a single low liquidity DEX trading pair with a short-time sample, aggregating the market manipulation risks.

Flash Loan Attacks

This type of attack is interconnected with the previous one since flash loans can be considered a tool to achieve price changes. In the flash loan attack, an exploiter borrows a large amount of funds through a flash loan and uses those funds to manipulate the price of an asset.

A flash loan attack is a type of exploit that takes advantage of the fact that flash loans are uncollateralized and do not require a credit check. In a flash loan attack, a hacker borrows a large amount of funds through a flash loan and uses those funds to manipulate the price of an asset on a DeFi platform.

It typically follows three steps:

1. Borrowing: The attacker initiates a flash loan by borrowing a significant amount of cryptocurrency from a DeFi platform that supports flash loans.
2. Execution: The attacker may use the borrowed funds to execute large buy or sell orders on decentralized exchanges, creating artificial price movements to their advantage.
3. Repayment: At the end of the transaction, the attacker repays the flash loan, returning the borrowed funds and any fees.

---

We couldn’t forget about our dear blockchain enthusiasts, so we curated a selection of insightful articles that will drastically boost your expertise:

• Flash Loan Attacks: Risks & Prevention https://hacken.io/discover/flash-loan-attacks/ 
• How To Consume Chainlink Price Feeds Safely https://0xmacro.com/blog/how-to-consume-chainlink-price-feeds-safely/
• Oracles, Entropy & Chainlink VRF Secure Integration Tips https://officercia.mirror.xyz/vUsNhI6GZhXWabifqFZqNmB93Fr0zsfIpCKBZEeEB7E
• Chainlink VRF Secure Integration Tips: Specifications
  https://blog.pessimistic.io/chainlink-vrf-secure-integration-tips-specifications-eafd63e87022
• Awesome Oracle Manipulation Repo https://github.com/0xcacti/awesome-oracle-manipulation
• Price Reward Manipulation attacks distilled https://blog.pessimistic.io/price-reward-manipulation-attacks-distilled-cfec2aa8feeb

Follow @hackenclub on 𝕏 (Twitter)