Source-linked AI summary
Foundational Oracle Patterns: Connecting Blockchain to the Off-chain World
Roman Mühlberger, Stefan Bachhofner, Eduardo Castelló Ferrer, Claudio Di Ciccio, Ingo Weber, Maximilian Wöhrer, Uwe Zdun
TL;DR
Blockchains cannot access off-chain state, and foundational oracle patterns had not been systematically classified and studied. The paper classifies patterns by data-flow direction and initiation, implements them in use cases, and analyzes their latency and cost. The patterns generally have distinct performance and cost profiles, while the measurements are preliminary and bounded by the studied cases.
Problem
Blockchains are closed-world systems, and foundational oracle patterns had not been closely investigated despite oracles’ role in transferring off-chain data.
Source: §1 · p. 2Method
The paper classifies oracles by inbound or outbound flow and push or pull initiation, implements the patterns in two use cases, and measures latency and cost.
Source: §1 · p. 2Results
The four patterns generally have distinct latency and cost distributions, neither is particularly high for a single invocation, and latency can be dominated by transaction inclusion time.
Source: §7 · p. 14Takeaways & Limitations
The foundational viewpoint separates concerns: changing an oracle’s information source requires revising the oracle without changing on-chain implementation logic.
Source: §6 · p. 13The analyses are preliminary rough indications, and Ropsten testnet measurements may be less representative of practical applications.
Source: §6 · p. 14
Abstract
from arXiv · showhide
Blockchain has evolved into a platform for decentralized applications, with beneficial properties like high integrity, transparency, and resilience against censorship and tampering. However, blockchains are closed-world systems which do not have access to external state. To overcome this limitation, oracles have been introduced in various forms and for different purposes. However so far common oracle best practices have not been dissected, classified, and studied in their fundamental aspects. In this paper, we address this gap by studying foundational blockchain oracle patterns in two foundational dimensions characterising the oracles: (i) the data flow direction, i.e., inbound and outbound data flow, from the viewpoint of the blockchain; and (ii) the initiator of the data flow, i.e., whether it is push or pull-based communication. We provide a structured description of the four patterns in detail, and discuss an implementation of these patterns based on use cases. On this basis we conduct a quantitative analysis, which results in the insight that the four different patterns are characterized by distinct performance and costs profiles.
1 Introduction
Blockchains support decentralized applications but cannot access off-chain state, creating a role for oracles and unresolved foundational questions about their design. The paper classifies oracle patterns by data-flow direction and initiator, then measures their performance and costs in two use cases.
1 Introduction
- Blockchain’s integrity, transparency, and resilience against censorship and tampering make it a platform for distributed applications.The passage cites applications including clinical trials, food security, and financial risk management.Source: §1 · p. 1
- Oracles transfer data between the outside world and blockchains, which otherwise expose only data already on-chain.Oracle implementations can introduce central points of failure or security and trust concerns.Source: §1 · p. 2
- The four foundational oracle patterns combine inbound or outbound data flow with push- or pull-based initiation.The patterns can be implemented without smart contracts and combined with higher-level patterns such as decentralization or provable computation.Source: §1 · p. 2
- More than 2,500 Ethereum test-network transactions across two use cases support quantitative comparisons of the patterns’ latency and cost.The implementations are based on Ethereum.Source: §1 · p. 2
2 Background and state of the art
The background surveys blockchain and oracle implementations, then positions the paper’s focus on outbound communication alongside the more established inbound-oracle work. It groups oracle implementations by their medium, source structure, and direction of communication.
2 Background and state of the art
- Oracles can be software, hardware, human, or computation-based, and can use single-source or consensus-based data sources.The paper abstracts from implementation form to focus on foundational patterns.Source: §2 · p. 3
- A blockchain ledger is a sequential, replicated transaction record linked by hashes, with consensus supporting eventual consistency.Smart contracts add programmable execution, with computation priced in gas.Source: §2 · p. 3
- Commercial inbound-oracle examples include Orisi, Oraclize, TinyOracle, Reality Keys, Chainlink, and Witnet, with differing architectures and push/pull classifications.Orisi is categorized as pull-based inbound; Oraclize can be both push- and pull-based inbound.Source: §2 · pp. 3–4
- Research examples include validation oracles, a decentralized voting-based pull oracle, and Town Crier, a push-based inbound oracle.The cited work distinguishes internal validation oracles that periodically transmit verified data from external validators that assess transactions.Source: §2 · p. 4
- Prior oracle efforts have largely focused on inbound data, while this paper also specifies outbound—or reverse—oracle patterns.A cited ISO/TC 307 technical report describes oracles solely as providers of off-chain information to blockchains.Source: §2 · p. 4
3 Patterns
The paper organizes oracle patterns by data-flow direction and initiator, then describes how each pattern moves information across the on-chain/off-chain boundary.
3 Patterns
- The four patterns combine inbound or outbound data flow with pull- or push-based initiation, separating oracle design by direction and communication strategy.The blockchain is treated as part of a larger system with components on and off-chain.Source: §3 · p. 4
3.1 Inbound Oracle
- Pull-based inbound oracles answer on-chain requests by retrieving off-chain state and returning it to the blockchain.Requests are traceable, but response time depends on blockchain speed and congestion may delay or prevent retrieval.Source: §3.1 · pp. 5–6
- Push-based inbound oracles monitor off-chain changes and forward information to the blockchain without requiring applications to query external data.Provision depends on off-chain applications, and compromising the source component can supply incorrect information.Source: §3.1 · p. 7
3.2 Outbound Oracle
- Pull-based outbound oracles let off-chain components query and filter blockchain data, decoupling status requests from retrieval.Data retrieval may take time depending on blockchain size and knowledge of the requested information's location.Source: §3.2 · pp. 7–8
- Push-based outbound oracles monitor blockchain changes and send relevant events off-chain, enabling actions when blockchain state updates.They must run continuously; unexpected stops may cause missed updates, and network speed can delay time-sensitive interactions.Source: §3.2 · p. 8
4 Use cases
The paper implements four oracle patterns in supply-chain use cases, including buyer creditworthiness checks and QR-code-based goods tracing. The tracing workflow combines inbound data propagation with two ways of exposing blockchain information off-chain.
4 Use cases
- The implementations use four oracle patterns in a supply-chain process where information flows to and from the blockchain.The oracles were implemented with Ethereum, Web3, and Python; QR-scan modules used QR-Code-Scanner.Source: §4 · p. 9
- A pull-based inbound oracle retrieves a bulk buyer's creditworthiness from an external assessment service before the manufacturer accesses the verified order.The order details go to a smart contract, whose event triggers the oracle request; the response is returned as transaction data.Source: §4 · pp. 9–10
- The QR-code tracing workflow sends scanned package data on-chain, forwards blockchain events to an ERP system, and serves product records to buyers on request.The inbound oracle enriches scan data with location and timestamp; a push-based outbound oracle transmits events, while a pull-based outbound oracle answers web-application queries.Source: §4 · p. 10
5 Analysis of Performance and Transaction Fees
The analysis measures latency and transaction costs across four oracle implementations. Results differ by pattern, with transaction inclusion contributing substantial delay to the push-based outbound oracle.
Setup
- The experiment uses Ethereum’s Ropsten testnet, measuring inbound-oracle costs by gas consumption and focusing on latency for outbound oracles.Inbound pull and push are evaluated with separate use-case contracts; outbound pull retrieval state is held constant, and only push-based inbound stores state and emits an event.Source: §5 · p. 11
- Latency is measured from transaction submission to receipt of its hash, while push-based outbound latency uses the block timestamp and event-receipt time.The analysis measures simple inclusion time without additional confirmation blocks, and notes that inclusion or commitment time varies across platforms and with network conditions.Source: §5 · pp. 11–12, Figure 10 · p. 11
Results
- 0.13±0.03 seconds for pull-based outbound versus 16.20±15.95 seconds for push-based outbound; the latter requires transaction inclusion.The authors attribute the gap to historical-state reads for pull-based outbound and transaction inclusion—with high variance and roughly 1.5 inter-block times of average delay—for push-based outbound.Source: §5 · p. 12, Figure 11 · p. 13
- The pull-based and push-based inbound oracles have similar central latency distributions, with means of 0.52±0.05 and 0.53±0.08 seconds, respectively.Both have a minimum of 0.46 seconds and median of 0.50 seconds; pull-based outbound transactions reach the third quartile within 0.12 seconds, compared with 21.44 seconds for push-based outbound.Source: §5 · p. 12
- At an 8.5-Gwei median gas price, estimated median transaction costs are 0.028 C for push-based inbound and 0.056 C for pull-based inbound.The Ropsten gas price was highly variable and not representative of mainnet; these estimates use mean gas consumption, the cited median gas price, and the exchange rate.Source: §5 · p. 12, Table 6 · p. 12
6 Discussion and Threats to Validity
The discussion highlights modularity: changing an oracle’s information sources need not require changes to on-chain logic. It also qualifies the performance and cost findings by their measurement and study scope.
Advantages
- Changing an oracle’s information sources requires revising the oracle, not the on-chain implementation logic.The authors describe the foundational pattern viewpoint as separating and composing concerns, allowing logic at distinct abstraction levels.Source: §6 · p. 13
Results discussion
- Sub-second latency was measured in almost all cases that excluded transaction inclusion time; other platforms or consensus algorithms may differ.The discussion compares this latency with a median transaction commit time of around 200 seconds in.Source: §6 · p. 13
- Latency and cost are described as not particularly high for single interactions, but the push-based inbound oracle incurs additional gas for state storage.The authors say storage can be optimized by storing data on-chain only when necessary, especially where many invocations could accumulate cost and delay.Source: §6 · p. 13
Limitations and threats to validity
- Qualitative pattern mining may have been influenced by misinterpretations or biases of individual researchers or the author team.The authors say such influences cannot be fully excluded.Source: §6 · p. 13
- The analyses are preliminary and provide only rough indications; Ropsten testnet use may reduce representativeness for practical applications.The authors do not claim completeness, and say generalizability beyond the studied cases would require more research.Source: §6 · pp. 13–14
7 Conclusion
The paper characterizes blockchain oracles through four foundational patterns and analyzes their latency and cost. The experiments find distinct performance distributions, with latency sometimes dominated by transaction inclusion.
Conclusion
- The paper abstracts existing technical solutions into four foundational oracle patterns and studies their relations, benefits, liabilities, and consequences.The patterns characterize communication between on-chain and off-chain realms.Source: §7 · p. 14
- Neither cost nor latency is particularly high for a single invocation, except that transaction inclusion can dominate latency; most patterns show different cost and latency distributions.The authors report these as findings from their experiments.Source: §7 · p. 14
Future work
- Future work includes multiple blockchain platforms, more use cases, data-rate and quantity effects on execution costs, and information exchange between blockchains.The authors also propose studying combinations of oracle patterns.Source: §7 · p. 14