Blockchain Oracle Design Patterns
saintsal last edited by saintsal
Amirmohammad Pasdar, Zhongli Dong, Young Choon Lee
Why do we need oracles?
Smart contracts and blockchain do not have access to the information outside of their networks (i.e., off-chain data). The blockchain in fact is an enclosed system where interactions are limited to the data available on it. Hence, it is still an open practical problem referred to as the “oracle problem” that is defined as how real-world data can be transferred into/from the blockchain.
Voting- or reputation-based
Voting relies on participants’ stakes for outcome finalization while reputation considers reputation in conjunction with authenticity proof mechanisms for data correctness and integrity.
Data feed services
respond to queries and may consult with different sources (or a single source) to fetch the required information and return it to the smart contracts.
perform user-defined computation-intensive tasks off-chain, providing computing power to the blockchains
- request-response when the data space is huge and can be implemented as on-chain smart contracts and initiated on-chain, or off-chain oracles for monitoring, retrieving, and returning data
- publish-subscribe when the data is expected to change, e.g., RSS feeds, and
- immediate read when the data is required for an immediate decision.
Source - online, hardware or human
Oracle sources can be chosen from (a) software oracles where data comes from online sources (e.g., online servers), (b) hardware oracles where data comes from the physical world (e.g., sensors), and © human oracles that are also responsible for verifying the authenticity of information and its translation into smart contracts.
Direction - in or out
Information direction means the way information flows; from/to external resources, e.g., a smart lock is an outbound oracle that once the payment is received at the address, unlocks the lock in the physical world.
Trust model - centralised or decentralised (permissionless)
Centralized oracles are efficient but they can be risky because a single entity provides information, controls the oracles, and a failure makes the contracts less resilient to vulnerabilities and attacks. In contrast, decentralized oracles (i.e., consensus-based oracles) increase the reliability of the information provided to the smart contracts by querying multiple resources. It should be noted that an oracle is considered decentralized if it is permissionless- users can join or leave, and every user has an equal privilege.
Consider integrity, confidentiality, and availability
Oracles are prone to be hacked; their process is vague, they can be bribed, and may not be stable . Also, smart contracts lack direct network access, and the use of transport layer security (TLS) to fetch information while keeping data untampered during transmission is not enough Hence, mechanisms should exist to digitally sign the data for verification, and in this regard, oracles are neither tamper-resistant nor trustless.
Oracles do not mainly hold security properties of native blockchain protocols, however, the correctness of the data can be attested through authenticity proof mechanisms, e.g., software-based [21, 22] or hardware-based approaches [6, 23].
To mitigate the issue in terms of the data correctness, users can form a set of voters and/or certifiers who are involved in the process of data correctness approval that is shown in Figure 3. Each voter and certifier put stakes on responses to verify the data. If the outcomes are matched, rewards are distributed between them, otherwise, they are penalized. It may also inherit the game theory concept Nash Equilibrium (e.g., [25–27]) defined as the determination of the optimal solution in a non-cooperative game in which each player does not have any incentive to alter the initial strategy.
Lazy equilibrium- a form of verifier’s dilemma- in which voters always return the same answer to questions to secure profits without performing works for correctness.
Sybil attacks: when attackers out-vote honest nodes on the network by creating multiple fake nodes to take over the network. A Sybil attacker can also employ mirroring that makes oracles to post individual responses based on a single data-source query.
Freeloading is another issue and defined as a cheating oracle obtains and copies the response of another oracle without paying per-query fees. This issue threatens the response time of oracles but can be addressed with commit and reveal strategy; sending cryptographic commitments to the responses and in the next round revealing the responses.
Prediction markets are platforms where financial shares in outcomes or facts are created, shared, and exchanged by participants. These platforms enable users to bet on anything, e.g., political forecasting, and receive compensation or become penalized if they are correct or wrong.
They are resistant to manipulation but also are largely scalable, and can help with the aggregation and distribution of unlimited information. Data in the prediction markets depends on the number of participants to take part in because the more participants, the more data and consequently, the more effective the prediction markets are. Prediction markets can be based on distributed oracles, e.g., the Delphi-based prediction market called Omphalos , and markets should have a tradable market price at all times known as the market liquidity.
Prediction markets can also be multi-dimensional markets in which users not only trade on the state probabilities but also the relationship between dimensions.
Astraea  is a general-purpose decentralized oracle running on the public ledger that relies on a voting-based game strategy. This framework employs monetary and staking fees which assure the system is immune to Sybil attacks. This oracle has entities that may have one or more roles such as submitters, voters, and certifiers who may freely join or exit the system. Boolean propositions are submitted to the system based upon paying a fee by submitters, and voters play a low-risk/low-reward game by placing a small stake of their confidence on the truth of random propositions. In contrast, certifiers play a high-risk/high-reward game by placing a large stake in the outcome of the selected voting and certification process.
The outcome of voting and certification is the stakeweighted sum of votes or certifies, respectively, and due to the random nature, it is resistant to manipulation. In weighted votes, the weight (and reward) is affected by the level of the deposit made as the higher the deposit, the heavier the weight, and the higher rewards and penalties. If the outcome of voters and certifiers are matched, they are rewarded, otherwise, the players who take the opposite position are penalized. Hence, this oracle encourages players to place bet/vote on the propositions that have such a high level of confidence. The voting and certification deposit should be small or large relative to the total voting stake on the proposition as the former could not control the outcome and the latter could be penalized and could not tamper with the outcome.
@saintsal What’s the difference between a Stake based and a Token based? Don’t you need a token to stake?