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.
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:
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.
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.
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.
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 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.
But not all stories have a happy ending. See oracle attacks where projects lost millions:
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.
Borrowing: The attacker initiates a flash loan by borrowing a significant amount of cryptocurrency from a DeFi platform that supports flash loans.
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.
Repayment: At the end of the transaction, the attacker repays the flash loan, returning the borrowed funds and any fees.
Security Recommendations From Hacken Team
Ensure that the price sources of all tokens cannot be manipulated.
Use the Chainlink oracle. They are more manipulation-resistant, provide highly accurate and fresh data, and have a wider market coverage as opposed to the TWAP (Time-weighted average price) algorithms.
When the Chainlink oracle is not available, TWAP oracles can be used. (it cannot always be considered a right decision). Here is an excellent comparison between both approaches created by the Chainlink team.
Set up monitoring tools to detect and alert anomalous on-chain activity, allowing quick interventions. Our company offers such a service, so donβt hesitate to contact the Extractor team.
We couldnβt forget about our dear blockchain enthusiasts, so we curated a selection of insightful articles that will drastically boost your expertise:
The blockchain industry has been grappling with scalability issues, which have hindered widespread adoption due to its technical constraints. As the demand for blockchain, decentralized applications (dApps), and transactions increases, the limitations of existing networks become increasingly apparent. High transaction fees and network congestion have plagued platforms like Ethereum, hampering their ability to support large-scale
The experimental semi-fungible token standard, ERC-404, combines elements from ERC-20 and ERC-721 tokens. Despite rising popularity, it has yet to secure an official Ethereum Improvement Proposal (EIP) designation. However, its unique attributes, such as enabling fractional ownership of NFTs and enhancing liquidity, coupled with the potential for automated NFT minting and burning processes, suggest a
Decentralized applications (dApps) are software that run on a decentralized network, often using blockchain technology. These applications can serve various purposes for end users, such as brokers, art collectors, traders, investors, and documents of public trust. However, their functionality and value attract malicious groups aiming to exploit vulnerabilities for financial gain. This article explores real-world examples of dApp security breaches, their attack vectors, and the lessons learned.