👁️Bitcoin Oracles 101
WTF is an oracle? 🤷🏽♂️
Oracles for Bitcoin L1 Blockchain
Oracles are applications that generate data feeds, making off-chain data sources accessible to the blockchain. This is crucial because, by default, Bitcoin-based systems cannot access information stored outside the blockchain network.
Integrating off-chain data with Bitcoin extends the utility and value of decentralized applications built on it. For instance, on-chain prediction markets rely on oracles to provide information about real-world outcomes to validate user predictions. Imagine Alice bets 0.5 BTC on who will become the next U.S. President. The prediction-market dapp needs an oracle to confirm election results and determine if Alice is eligible for a payout.
Torrams' Bitcoin Oracles will allow for data feeds from other blockchain data sources and real world off-chain data sources (stock market data, sports scores, weather data, etc.) to be accessible natively on bitcoin blockchain
PREREQUISITES This page assumes the reader is familiar with Bitcoin fundamentals, including nodes, consensus mechanisms, and transaction validation. A good grasp of the basics of blockchain technology is recommended.
WHAT IS A BLOCKCHAIN ORACLE?
Oracles are applications that source, verify, and transmit external information (i.e., information stored off-chain) to blockchain-based applications. Besides "pulling" off-chain data and broadcasting it on the Bitcoin blockchain, oracles can also "push" information from the blockchain to external systems, such as unlocking a smart lock once a user sends a fee via a Bitcoin transaction.
Without an oracle, blockchain-based applications would be limited to on-chain data.
Oracles differ based on the source of data (one or multiple sources), trust models (centralized or decentralized), and system architecture (immediate-read, publish-subscribe, and request-response). We can also distinguish between oracles based on whether they retrieve external data for use by on-chain contracts (input oracles), send information from the blockchain to off-chain applications (output oracles), or perform computational tasks off-chain (computational oracles).
WHY DO BITCOIN-BASED APPLICATIONS NEED ORACLES?
Many see blockchain applications as code running at specific addresses on the blockchain. However, a more general view is that they are self-executing software programs capable of enforcing agreements between parties once specific conditions are met.
But using these applications to enforce agreements between people isn't straightforward, given that Bitcoin is deterministic. A deterministic system always produces the same results given an initial state and a particular input, meaning there is no randomness or variation in the process of computing outputs from inputs.
To achieve deterministic execution, blockchains limit nodes to reaching consensus on simple binary (true/false) questions using only data stored on the blockchain itself. Examples of such questions include:
“Did the account owner (identified by a public key) sign this transaction with the paired private key?”
“Does this account have enough funds to cover the transaction?”
“Is this transaction valid in the context of this script?”, etc.
If blockchains received information from external sources (i.e., from the real world), determinism would be impossible to achieve, preventing nodes from agreeing on the validity of changes to the blockchain’s state. For example, a blockchain application that executes a transaction based on the current BTC-USD exchange rate obtained from a traditional price API would face issues since this figure is likely to change frequently (not to mention that the API could get deprecated or hacked), leading nodes executing the same code to arrive at different results.
For a public blockchain like Bitcoin, with thousands of nodes worldwide processing transactions, determinism is critical. With no central authority serving as a source of truth, nodes need mechanisms for arriving at the same state after applying the same transactions. A scenario whereby node A executes a script and gets "3" as a result, while node B gets "7" after running the same transaction would cause consensus to break down and eliminate Bitcoin’s value as a decentralized computing platform.
This scenario also highlights the problem with designing blockchains to pull information from external sources. Oracles, however, solve this problem by taking information from off-chain sources and storing it on the blockchain for applications to consume. Since information stored on-chain is immutable and publicly available, Bitcoin nodes can safely use the oracle-imported off-chain data to compute state changes without breaking consensus.
To do this, an oracle typically consists of an on-chain component (a script or smart contract) and off-chain components (oracle nodes). The on-chain component receives requests for data from other scripts, which it passes to the off-chain component. This oracle node can query data sources—using APIs, for example—and send transactions to store the requested data on-chain.
Essentially, a blockchain oracle bridges the information gap between the blockchain and the external environment, creating “hybrid applications.” Hybrid applications function based on a combination of on-chain script code and off-chain infrastructure. Decentralized prediction markets are an excellent example of hybrid applications. Other examples might include crop insurance smart contracts that pay out when a set of oracles determines that certain weather phenomena have occurred.
WHAT IS THE ORACLE PROBLEM?
Oracles solve an important problem but also introduce complications, such as:
How do we verify that the injected information was extracted from the correct source or hasn’t been tampered with?
How do we ensure that this data is always available and updated regularly?
The so-called “oracle problem” demonstrates the issues that come with using blockchain oracles to send inputs to applications. Data from an oracle must be correct for a smart contract to execute correctly. Further, having to ‘trust’ oracle operators to provide accurate information undermines the 'trustless' aspect of smart contracts.
Different oracles offer different solutions to the oracle problem. Oracles are typically evaluated on how well they handle the following challenges:
Correctness: An oracle should not cause applications to trigger state changes based on invalid off-chain data. An oracle must guarantee the authenticity and integrity of data. Authenticity means the data was obtained from the correct source, while integrity means the data remained intact before being sent on-chain.
Availability: An oracle should not delay or prevent applications from executing actions and triggering state changes. This means that data from an oracle must be available on request without interruption.
Incentive compatibility: An oracle should incentivize off-chain data providers to submit correct information to applications. Incentive compatibility involves attributability and accountability. Attributability allows linking a piece of external information to its provider, while accountability bonds data providers to the information they give, so they can be rewarded or penalized based on the quality of information provided.
HOW DOES A BLOCKCHAIN ORACLE SERVICE WORK?
Users:
Users are entities (i.e., scripts) that need external information to complete specific actions. The basic workflow of an oracle service starts with the user sending a data request to the oracle contract. Data requests usually answer some or all of the following questions:
What sources can off-chain nodes consult for the requested information?
How do reporters process information from data sources and extract useful data points?
How many oracle nodes can participate in retrieving the data?
How should discrepancies in oracle reports be managed?
What method should be implemented in filtering submissions and aggregating reports into a single value?
Oracle contract:
The oracle contract is the on-chain component for the oracle service. It listens for data requests from other contracts, relays data queries to oracle nodes, and broadcasts returned data to client contracts. This contract may also perform some computation on the returned data points to produce an aggregate value to send to the requesting contract. The oracle contract exposes functions that client contracts call when making a data request. Upon receiving a new query, the smart contract will emit a log event with details of the data request. This notifies off-chain nodes subscribed to the log, who proceed to retrieve data defined in the log event.
Oracle nodes:
The oracle node is the off-chain component of the oracle service. It extracts information from external sources, such as APIs hosted on third-party servers, and puts it on-chain for consumption by smart contracts. Oracle nodes listen for events from the on-chain oracle contract and complete the task described in the log. A common task for oracle nodes is sending an HTTP GET request to an API service, parsing the response to extract relevant data, formatting it into a blockchain-readable output, and sending it on-chain by including it in a transaction to the oracle contract. The oracle node may also be required to attest to the validity and integrity of submitted information using “authenticity proofs.”
ORACLE DESIGN PATTERNS
Oracles come in different types, including immediate-read, publish-subscribe, and request-response, with the latter two being the most popular among blockchain applications. Here we briefly describe the publish-subscribe and request-response models.
Publish-subscribe oracles: This type of oracle exposes a “data feed” which other contracts can regularly read for information. The data in this case is expected to change frequently, so client contracts must listen for updates to the data in the oracle’s storage. An example is an oracle that provides the latest BTC-USD price information to users.
Request-response oracles: A request-response setup allows the client contract to request arbitrary data other than that provided by a publish-subscribe oracle. Request-response oracles are ideal when the dataset is too large to be stored in a smart contract’s storage, and/or users will only need a small part of the data at any point in time. The oracle will have an on-chain component that receives a data request and passes it to an off-chain node for processing.
Users initiating data queries must cover the cost of retrieving information from the off-chain source. The client contract must also provide funds to cover gas costs incurred by the oracle contract in returning the response via the callback function specified in the request.
CENTRALIZED VS. DECENTRALIZED ORACLES
Centralized oracles:
A centralized oracle is controlled by a single entity responsible for aggregating off-chain information and updating the oracle contract's data as requested. Centralized oracles are efficient since they rely on a single source of truth. They may function better in cases where proprietary datasets are published directly by the owner with a widely accepted signature. However, they bring downsides such as low correctness guarantees, poor availability, and poor incentive compatibility.
Decentralized oracles:
Decentralized oracles are designed to overcome the limitations of centralized oracles by eliminating single points of failure. A decentralized oracle service comprises multiple participants in a peer-to-peer network that form consensus on off-chain data before sending it to a smart contract. Decentralized oracles should ideally be permissionless, trustless, and free from central administration. They use various methods such as voting/staking on accuracy, authenticity proofs, and consensus-based validation to ensure high correctness guarantees, availability, and good incentive compatibility.
APPLICATIONS OF ORACLES IN BITCOIN-BASED APPLICATIONS
Retrieving financial data: Decentralized finance (DeFi) applications allow for peer-to-peer lending, borrowing, and trading of assets. This often requires getting different financial information, including exchange rate data and capital markets data.
Generating verifiable randomness: Certain blockchain applications, such as games or lottery schemes, require unpredictability and randomness. Oracles can securely generate random outcomes off-chain and broadcast them on-chain along with cryptographic proofs attesting to the process's unpredictability.
Getting outcomes for events: Oracles enable creating smart contracts that respond to real-world events by connecting to external APIs and consuming information from those data sources.
Automating smart contracts: Smart contracts do not run automatically; an externally owned account or another contract must trigger the right functions. Decentralized oracle networks offer automation services, allowing off-chain oracle nodes to trigger smart contract functions based on user-defined parameters. (This will soon be possible with Arch Network's bitcoin-native smart contracts, for example)
By understanding and implementing oracles effectively, Bitcoin-based applications can bridge the gap between the blockchain and the real world, enhancing their functionality and reliability.
Voting/Staking on Data Accuracy
In some decentralized oracle networks, participants vote or stake on the accuracy of answers to data queries (e.g., "What was the outcome of the 2020 US election?") using the network’s native tokens. An aggregation protocol then combines these votes and stakes to determine the consensus answer.
Nodes that provide answers deviating from the majority are penalized by redistributing their tokens to those who gave more accurate responses. By requiring nodes to stake tokens before submitting data, the system incentivizes honesty, assuming that participants act rationally to maximize their returns.
This staking/voting mechanism also helps protect decentralized oracles from “Sybil attacks,” where malicious actors might create multiple identities to manipulate the system. However, staking does not completely prevent issues like “freeloading” (nodes copying information from others) and “lazy validation” (nodes following the majority without verifying data).
Schelling Point Mechanisms Schelling point is a game theory concept suggesting that, in the absence of communication, multiple entities will converge on a common solution. This mechanism is often used in decentralized oracle networks to achieve consensus on data.
An early concept, SchellingCoin, proposed a data feed where participants submitted answers to scalar questions (e.g., "What is the price of BTC?") along with a deposit. Those whose answers fell within the interquartile range (25th to 75th percentile) were rewarded, while outliers were penalized.
Although SchellingCoin isn't active today, several decentralized oracles use similar Schelling-point mechanisms. These systems aggregate responses from multiple oracle nodes into a single value, such as a mean or median, rewarding nodes whose answers align closely with this aggregate value.
These mechanisms are advantageous because they minimize the on-chain footprint (only one transaction is needed) while ensuring decentralization. Nodes must sign off on submitted responses before they are processed, enhancing trust in the final aggregate value.
Ensuring Availability Decentralized oracle services ensure high availability of off-chain data for applications on the Bitcoin blockchain. This is achieved by decentralizing both the sources of off-chain information and the nodes responsible for transferring this information on-chain.
Decentralization at both the source and node level ensures fault tolerance. Oracle contracts can rely on multiple nodes (and multiple data sources) to handle data queries, avoiding single points of failure that plague centralized oracles.
Stake-based oracles may also penalize node operators who fail to respond promptly to data requests, incentivizing nodes to maintain reliable, fault-tolerant infrastructure and deliver timely data.
Incentive Compatibility Decentralized oracles incorporate incentive mechanisms to prevent malicious behavior among nodes. They achieve attributability and accountability by:
Requiring nodes to sign the data they provide, which helps track the performance history of oracle nodes. This allows users to filter out unreliable nodes when making data requests.
Implementing a staking system where nodes place a stake on the accuracy of the data they submit. If the data is accurate, the stake is returned with rewards; if not, the stake is forfeited, providing accountability for the information provided.
By leveraging runes and ordinals, Bitcoin-based oracles can bridge the gap between off-chain data and on-chain applications. This enhances the functionality and reliability of Bitcoin applications while maintaining the network’s principles of decentralization and integrity.
Last updated