A Study of Blockchain Oracles

I. INTRODUCING BLOCKCHAIN ORACLE

• Oracles query, verify, authenticate, and relay off-chain information to smart contracts, sometimes also sending information outward.They can transmit information such as payments or sensor temperatures, but invoking external data consumes network resources.Source: §I · p. 1
• The paper surveys widely used oracle types, their potential roles, technical architectures, design patterns, human-oracle consensus, use cases, and limitations.Oracle operation depends on the functions and characteristics for which each design is intended.Source: §I · p. 1

II. TYPES OF BLOCKCHAIN ORACLE

• Oracle classifications consider whether data comes from software, hardware, or humans, whether information is inbound or outbound, and whether trust is centralized or decentralized.A single oracle may belong to multiple categories, such as a centralized inbound software oracle sourcing data from a company website.Source: §II · p. 1

A. Software Oracles

• Software oracles retrieve online information and transmit it to blockchains, often supplying real-time exchange rates, asset prices, flight data, or other web information.Their Internet connectivity supports real-time delivery and makes them one of the most common oracle types.Source: A. Software Oracles · p. 1

B. Hardware Oracles

• Hardware oracles translate physical-world events into digital values through sensors, IoT devices, scanners, RFID tags, robots, or other readers.A sensor can report a truck’s arrival at a loading bay so a smart contract can execute a decision.Source: B. Hardware Oracles · p. 1

C. Human Oracles

• Human oracles research and verify information, translate it to smart contracts, and can answer arbitrary unstructured inquiries that machines may struggle to deduct automatically.Cryptographic identity verification makes fraudulent identity claims relatively unlikely.Source: C. Human Oracles · pp. 1–2

D. Computation Oracles

• Computation oracles perform calculations off-chain and return results that may be infeasible or expensive to compute on-chain.A computationally intensive regression can estimate a bond contract’s yield.Source: D. Computation Oracles · p. 2

E. Inbound/Outbound Oracles

• Inbound oracles send external information to smart contracts, whereas outbound oracles send contract information to the external world.Examples include reporting sensor temperature inbound and triggering a smart-lock mechanism outbound after funds are deposited.Source: E. Inbound/Outbound Oracles · p. 2

F. Contract-specific Oracles

• Contract-specific oracles serve one smart contract and must be replicated proportionally for multiple contracts.They are time-consuming and expensive to maintain, but offer flexibility for tailoring a design to a specific use case.Source: F. Contract-specific Oracles · p. 2

G. Consensus-based Oracles

• Consensus-based oracles combine multiple oracle responses, such as averaging five or requiring five of seven agreements, to reduce reliance on a single source.They are slower because reaching consensus takes more time, but may be safer when oracle accuracy or trust is uncertain.Source: G. Consensus-based Oracles · p. 2

III. CENTRALIZED/DECENTRALIZED ORACLES

• Centralized oracles create a single point of failure because one entity solely supplies information, so malicious interference directly affects contract execution.Decentralized oracles query multiple providers and distribute trust rather than eliminating it completely.Source: §III · p. 2
• Decentralized oracles can support prediction markets by verifying outcomes through social consensus and can provide services across blockchains.Their purpose includes improving reliability without relying on a single source of truth.Source: §III · p. 2

1) General Concepts:

• Provable’s decentralized alternative avoids the inefficiency of collecting enough answers from multiple parties, which requires fees, time, and standardized data formats.The system can use auditable virtual machines or Trusted Execution Environments to support authenticity proofs.Source: 1) General Concepts · p. 3
• Provable addresses intermediary trust by returning authenticity proofs showing that fetched data is genuine and untampered.Its approach avoids requiring application developers and users to trust Provable while preserving the blockchain security model.Source: 1) General Concepts · p. 3
• Provable supports direct smart-contract access to websites or APIs and integrates with private and public blockchain protocols.Its service is described as operating across platforms including Ethereum, R3 Corda, Hyperledger Fabric, and EOS.Source: 1) General Concepts · pp. 2–3

2) Provable Engine:

• The Provable Engine replicates an “If This Then That” model, executing instructions when specified conditions are met.It can repeatedly verify a condition and return data or perform an action only after that condition is satisfied.Source: 2) Provable Engine · p. 3
• A valid Provable request specifies a data-source type and may also specify an authenticity-proof type.Requests can be made through native blockchain integration or the HTTP API.Source: 2) Provable Engine · p. 3

3) Data Source Types:

• Provable data sources include websites or APIs, WolframAlpha, IPFS, secure random data, and arbitrary computation.These sources may use web providers, hardware-enforced TEEs, or auditable locked-down virtual machines.Source: 3) Data Source Types · p. 3
• Metadata sources extend the system through nested requests, query-returning identity operations, and decryption using the Provable private key.Nested sources combine different source types or multiple requests into one unique result.Source: 3) Data Source Types · p. 3

4) Query:

• A query is an array of parameters evaluated to complete a specific data-source request.The first parameter is usually mandatory; URL requests use it for the resource location, while an optional second parameter carries an HTTP POST payload.Source: 4) Query · p. 3

5) Parsing Helpers:

• Queries can include parsing helpers when an intermediate result must be reduced to a precise field.The paper describes helpers for JSON, XML, XHTML, and binary responses.Source: 4) Query · p. 3, 5) Parsing Helpers · p. 3
• JSON and XML helpers extract specified elements from API responses, while the HTML helper supports scraping through an XPath argument.The binary helper returns a slice specified by offset and length.Source: 5) Parsing Helpers · p. 3

6) Authenticity Proofs:

• Authenticity proofs attach a cryptographic guarantee that delivered data or computation results were not tampered with.Anyone can verify the proof to assess whether the result is authentic.Source: 6) Authenticity Proofs · pp. 3–4

1) Overview:

• ChainLink bridges on-chain and off-chain environments through modular, replaceable components intended to support multiple smart-contract networks.Its nodes return replies to requests made by USER-SC through the on-chain CHAINLINK-SC interface.Source: 1) Overview · p. 4, 2) On-Chain Architecture · p. 4

2) On-Chain Architecture:

• The on-chain workflow comprises oracle selection, data reporting, and result aggregation.Purchasers specify SLA requirements, including query parameters, oracle count, reputation contracts, and aggregation contracts.Source: 2) On-Chain Architecture · p. 4
• Order-matching contracts automate selection by accepting qualified bids, attaching penalties for misbehavior, and finalizing an SLA after the bidding window.Manual matching remains possible through off-chain listings, while automated matching supports dynamic service requests.Source: 2) On-Chain Architecture · p. 4
• Aggregation is configurable because detecting outliers depends on the data feed and application, with standard or customized contracts calculating the collective result.The aggregating contract also feeds oracle-performance metrics back into the reputation contract.Source: 2) On-Chain Architecture · p. 4

3) Off-Chain Architecture:

• Independent oracle nodes harvest off-chain responses and aggregate them through consensus into a global response returned to USER-SC.The nodes use core software for blockchain interaction, scheduling, and external resources, while external adapters add specialized services.Source: 3) Off-Chain Architecture · pp. 4–5
• ChainLink Core processes assignments as pipelines of subtasks, including HTTP requests, JSON parsing, and conversion to blockchain formats.Each subtask performs an operation before passing its result to the next stage.Source: 3) Off-Chain Architecture · p. 5
• External adapters expose custom subtasks through minimal REST APIs, simplifying specialized programs and complex multi-step APIs.JSON Schemas specify adapter inputs and outputs to maintain compatibility across independently developed adapters.Source: 3) Off-Chain Architecture · p. 5

4) ChainLink Workflow:

• Requests can be distributed across both oracles and data sources, as illustrated by the ChainLink workflow and its two-level distribution.The paper also introduces commitment and reveal phases in which a value remains hidden before later verification.Source: 4) ChainLink Workflow · p. 5, 5) Commit-Reveal Scheme · p. 5

IV. HUMAN ORACLES

• Human oracles create truth by reaching consensus about an inquiry, and can therefore function as multi-source oracles.The paper examines this approach in prediction markets and for structured data.Source: §IV · p. 5

A. Background

• Truth-by-consensus presents individuals with questions or reporting cards and uses tradeable incentives, such as tokens, to encourage truthful responses.The discussion relates this design to Buterin’s SchellingCoin proposal [2] and Schelling’s game-theoretical work.Source: A. Background · p. 5
• Deposits and challenges can encourage participants to report what they expect the majority to consider correct and can impede Sybil attacks when the network is sufficiently large and distributed.The mechanism targets agreement on a state of fact rather than direct transfer from a pre-existing source.Source: A. Background · p. 5, §IV · p. 5
• Schelling-based consensus does not guarantee objective truth because a majority may share misinformation, and blockchain records cannot be corrected retroactively.The paper therefore cautions that consensus-based truth should be treated carefully.Source: A. Background · pp. 5–6
• Ambiguous inquiries can fail when unspecified factors, such as time zone, lead participants to answer different versions of the question.The Bitcoin-price example illustrates how missing query conditions can undermine agreement.Source: A. Background · p. 6

B. Application in Prediction Markets

• Human oracles create truth by reaching consensus, and prediction markets such as Augur and Gnosis use consensus-based approaches to resolve facts.Augur uses reputation-token reporting until a preset quorum, while Gnosis lets users challenge centralized oracle results through deposited Ether.Source: B. Application in Prediction Markets · p. 6
• Gnosis’s challenge mechanism can be dominated by wealthy participants because its 100-Ether deposit may enable bullying and unjustified losses.Source: B. Application in Prediction Markets · p. 6

C. Adoption to Structured Data

• Human-oracle reporting for structured data would require extensive manual participation, but human cognition is costly and slow, limiting throughput and real-time use.The paper describes manual-input oracles as resource-intensive and able to handle only a limited set of questions at once.Source: C. Adoption to Structured Data · p. 7
• Reporting pools do not comprehensively solve human-oracle weaknesses because a malicious actor may influence voting and recreate a single point of failure.Source: C. Adoption to Structured Data · p. 7

V. ORACLE DESIGN PATTERNS

• Oracle designs collect off-chain data, transfer it on-chain with signed messages, and expose it through smart-contract storage for other contracts or clients.Source: §V · p. 7

A. Immediate-Read

• Immediate-read oracles store lookup-oriented data for just-in-time access, potentially using hashes or Merkle-tree roots instead of raw certificates or private identifiers.Source: §V · p. 7, A. Immediate-Read · p. 7

B. Publish-Subscribe

• Publish-subscribe oracles broadcast changing data through storage updates or event signals, allowing subscribers to poll or watch for new information.This pattern suits price feeds, weather information, economic statistics, and traffic data.Source: B. Publish-Subscribe · p. 7
• Smart-contract polling can incur significant gas expenditure, although client-side polling and Ethereum event logs make update monitoring comparatively efficient.Source: B. Publish-Subscribe · p. 7

C. Request-Response

• Request-response oracles serve small portions of large datasets through asynchronous on-chain requests, off-chain retrieval, signed responses, and returned transactions.The workflow can include query parsing, payment and permission checks, data retrieval, transaction signing, broadcasting, and scheduling further updates.Source: C. Request-Response · pp. 8–9
• Request-response is less suitable for slowly changing data, so publish-subscribe can reduce bandwidth when a smart bond repeatedly needs an interest rate.Source: C. Request-Response · p. 9
• Publish-subscribe lets multiple DApps read updated values from oracle storage, while broadcast channels can provide either full histories or only the latest value.Source: C. Request-Response · p. 9

• Physical-source randomness can fairly select winners in lottery smart contracts, while hazard measurements can trigger catastrophe-bond contracts.Source: §VI · p. 9
• Static identifiers, time intervals, and weather data support identity, event-trigger, and insurance applications.Source: §VI · p. 9
• Oracle inputs can resolve political and sporting prediction markets, verify insurance damage, and support supply-chain tracking through geolocation data.Source: §VI · p. 9
• Oracles can relay events from other blockchains, Ether prices, exchange rates, capital-markets data, and benchmark references for interoperable and financial contracts.Source: §VI · p. 9
• Flight statistics can support flight-ticket pooling by groups and clubs.Source: §VI · p. 9

• Compromised trusted oracles or data sources can feed false inputs and compromise smart-contract execution.Source: §VII · p. 9
• Decentralized oracles can address some trust concerns by providing Ethereum smart contracts with trust-less external data.Source: §VII · p. 9