Blockchain Oracle Implementation Framework

Oracles and Data
,
1

Mammadzada, Kamran & Iqbal, Mubashar & Milani, Fredrik & García-Bañuelos, Luciano & Matulevičius, Raimundas. (2020). Blockchain Oracles: A Framework for Blockchain-Based Applications. 10.1007/978-3-030-58779-6_2.

Core Research Question

What are the best practices for understanding the different blockchain oracle implementations?

Method

Meta-analysis/systematic literature review.

Reviewing 23 studies across blockchain oracle technology research, authors examined how oracles implement data origination, oracle properties, oracle encryption standards, data source decentralization, data validation, and blockchain integration methods.

Findings

  • Data origination
    • Types
      • Web data
        • Generic Https data
      • Sensor data
        • Wearable devices
        • RFID
        • Embedded road sensors
  • Oracle properties - Physical attributes of the oracle
    • Types
      • Software oracles – oracles that push information available online to blockchain
      • Hardware oracles – oracles that push information from physical devices (e.g. sensors, RFID chips, etc.) into the blockchain
      • Inbound oracles – oracles that provide smart contracts with data from the
      • external world
      • Outbound oracles – oracles that send information to the outside world
      • Consensus-based oracles – data passed to blockchain is treated as a result of consensus of multiple oracles
  • Oracle encryption method
    • Type
      • Public Key
        • TLS
        • TLS-N
        • Other
      • Symmetric
      • Asymmetric
        • ECC
        • ECC-TC
        • Other
  • Data source decentralization
    • Types
      • Single source
      • Multiple source
  • Data validation
    • Types
      • Consensus
        • Majority voting
        • Weighted voting
        • Hybrid PoW/PoS
      • No data validation
        • Trusted third party
      • Self-validation
        • RFID signature validation
  • Blockchain integration methods
    • Types
      • Smart contract integration
        • On-chain and off-chain smart contract
        • Off-chain smart contracts deployed on-chain
        • Data storage smart contract (DSSC)
        • Information sharing smart contract (ISSC)
        • Chaincode (specialised smart contract)
        • On-chain smart contract accessing Data Cubes
        • Smart contract able to verify TLS-N proofs
        • Server + on-chain smart contract
        • On-chain smart contract + Bridge node
        • TLS Identities linked to content contract
      • Software module
        • RFID Reader + PC with blockchain module
        • Software module (ETSE) + Adapter
        • Control System + Blockchain client
        • Patient centric agent
      • Custom solution
        • Blockchain identity bound to government ID
        • OriginStamp
      • Built-in
      • Other methods unaccounted for in study
  • Authors propose that evaluating oracles should be done in a stepwise manner by examining each stage of the process to fully understand what type of oracle solution will be available.

1600×870 286 KB

A more graphically intuitive model is also presented:

1600×1163 158 KB

The authors suggest that engineers can use this model to evaluate the components of a given oracle platform.

Discussion

The authors rightfully acknowledge the challenge in conducting a meta-analytic review of published work in blockchain, especially with regard to new solutions and constant innovation. As a basic framework, these six categories and proposed conceptual flow make intuitive sense, however real-world oracle implementation does not follow basic frameworks. In real-world oracle implementations we see solutions take multiple strategies for their available service offerings. For example, a project may have web data, API data, and IoT sensor data available as part of their oracle solution. In implementation it can be unclear whether those solutions are several oracle frameworks under a singular label - this is part of the due diligence integration process, and the authors framework can still be helpful for developers working through the various options.

Proposed questions (for the authors and community):

  • What additional elements can we add to the framework, whether published or not?
  • Should oracle solutions that offer multiple frameworks be evaluated for each oracle type according to these lines?
  • Are there interaction effects that change how the evaluation framework can be interpreted?
  • Is API data included in general web data? Does API data change the data type category?
  • What are the strengths and weaknesses for any of the proposed categories?
  • What are the strengths and weaknesses for particular implementations across categories?
  • How do we evaluate category implementations with limited and skewed data?
3 Likes