Oracles and Event Triggers

Authors: Dileban Karunamoorthy, Ziyuan Wang, John Wagner, Ermyas Abebe

Introduction
This document is intended to solicit feedback from the community on a proposal for an
oracle service for permissioned networks such as Hyperledger Fabric. This follows from
having examined a number of oracle implementations (see Appendix A) currently available.
In general, these implementations fall in two categories. The first is decentralized
blockchain-based oracle networks that leverage crypto-economics to incentivize participants
to contribute resources (such as oracle nodes) in return for tokens that have monetary value.
These networks are primarily targeted at public blockchains and are unsuited for
permissioned networks where data privacy and confidentiality are key concerns. The second
comprises gateway services that provide authenticity guarantees on the data feeds sourced
from third-party APIs while placing less trust on the gateway service itself. These services
have been purpose built for specific blockchain implementations and requires significant
rewrite to support other implementations such as Fabric. Furthermore, these
implementations address the problem of sourcing data on behalf of Smart Contracts, but are
not designed to address a general purpose gateway for interfacing blockchain networks with
the external world. For instance, actuating external processes or devices.

Today, while it is possible to implement custom oracles on a case by case basis, a large
portion of this effort can be removed through a standard service and framework. This allows
developers to rapidly deploy oracle services or event triggers for the applications and focus
primarily on the data and events that concern their use case, and less on authentication,
request deduplication and orchestration of transaction call-backs.

NOTE: This document is not a technical specification.

Background
Smart Contracts allow networks to encode agreed upon business rules that validate and
execute transactions as part of an overall distributed business process. Smart Contracts are
executed in parallel and independently, on multiple trust domains to tolerate Byzantine
failures, but are constrained by the environments they run in. Deterministic execution
requires contracts to rely on network participants for inputs or use existing state on the
blockchain during execution.

Contracts also rely on network participants to interface with the external world in order to
trigger critical processes that affect multiple parties external to the blockchain, such as
triggering payment transfers or the shipment of goods.
Dependence on individual actors in a network, for data inputs or triggering actions in the real
world, assumes a higher degree of trust and fault-tolerance.

Proposal
A service and framework for implementing a gateway between a blockchain network such as
Hyperledger Fabric and the external world, allowing programmers to create and deploy
custom oracles and event triggers that would operate under the same trust assumptions of a
permissioned ledger.

Value Proposition
Increased Trust in Input Data:​ Removing the need to trust a single network participant for
critical input data increases trust in the overall network. This requires enabling Smart
Contracts to access off-chain data such as pricing or sanctions lists directly to preserve
similar levels of trust in permissioned networks.

Increased Trust in Actuating External Processes: ​Critical business processes (such as

payments or the shipment of goods) external to the blockchain that affect multiple
participants can be executed with greater trust and reliability.

Increased Trust in Initiating Transactions: ​Removing the need to rely on individual

network participants to initiate critical transactions that affect other participants increases
trust in the overall network. Transactions can be initiated based on a number of conditions
such as time (including periodic intervals), or specific events (both on-chain and off-chain)
For example, automatic payments to farmers in parametric-based insurance when certain
dryness thresholds in vegetation is reached. “Expiration” of records on a ledger at a
specified future date.

Features
Feature Description

Gateway Service Supports authentication and transaction call management and

multiple blockchain implementations.

Oracles for Data Inputs
Pre-built oracles for common well-known use cases (e.g. RNG,
time of day, secure sequencer. Open for discussion). Framework
and libraries for implementing custom oracles. Oracles are
containerized processes, written in any programming language
and controlled by the gateway service.

Time Based Scheduling Trigger execution of contracts based on time, either a one off or
recurring invocations.
 ● Guarantees on hard time is difficult to achieve in
distributed systems spanning multiple trust domains.
● Requires knowledge of underlying blockchain protocol to
orchestrate invocation.

Event Based Scheduling Trigger execution of contracts based on external events

of interest.
● External events are monitored by custom oracles.
● Requires knowledge of underlying blockchain protocol to
orchestrate invocation.

Event Triggers Framework and libraries for implementing custom event triggers.
These are containerized processes, written in any programming
language and controlled by the gateway service.
● Trigger external events through explicit calls by contracts.
● Trigger external events by “watching” for specific state
changes on the ledger.

Ledger Updates Based on Updates to ledger for future use by contracts. Updates based on
Time and Events external events such newly published sanctions lists by a
government agency, or periodic updates such as daily changes to
pricing information.

Libraries for Smart A set of client libraries for Smart Contracts for easy interaction with
Contracts the gateway service.

Future Considerations It is possible to address more interesting use cases in future, such
as running continuous queries against disparate data sources and
triggering the execution of a Smart Contract with specific
conditions are met.

Design Considerations and Challenges

Trust: ​The following trust assumptions allow us to start with a simplified approach:
● The identities on the network are known and trusted a priori.
● The network (or consortium) trusts external entities they interface with, such as a
government agency or banks for payment processing.
● The service runs in a trust domain that is acceptable to the network (e.g. the same
trust domain of the ordering service in a Hyperledger Fabric network)

Time: ​Real time guarantees are hard to achieve, particularly in distributed systems that span
multiple trust domains.
 ● Left to consortium to define acceptable time windows and understand ramifications
of failure to meet hard deadlines.

Data and Event Retention: ​The service can maintain a complete audit trail of data sources
and events triggered to address potential disputes.
● Maintained in a local database or written to a multi party ledger.

High Stake Scenarios: ​High Stake scenarios such as a high value financial transactions
that depend on specific conditions external to the blockchain may require further diligence.
● Should multiple parties vote on validity and accuracy of data to trigger contract
execution?

Conceptual Architecture
Appendix A

Current Landscape of Oracles

Microsoft Coco Framework

The Coco Framework supports multiple blockchain implementations (currently Ethereum,
Quorum, Corda, or Hyperledger Sawtooth). The network is assumed to be trusted and the
framework leverages TEEs such as Intel’s SGX or Windows Virtual Secure Mode to reduces
Byzantine fault tolerance to crash fault tolerance. Smart Contract is only executed on a
single node for a given transaction and thus can support non-deterministic execution
(e.g.randomness or call out to trusted external services).

Pros
● Eliminates the problem of non-determinism as the smart contract is only executed on
a single node.
Cons
● Assumes network is trusted and not designed to tolerate Byzantine failures.
● Contracts must trust external data sources.
Microsoft Bletchley - Cryptlets
Superseded by Microsoft’s Coco Framework and described here for design reasons.
Bletchley supports multiple blockchain implementations (Ethereum, Eris). The functionality
of oracles are provided by Utility and Contract Cryptlets. Utility Cryptlets provide services
such as encryption, time and date events, external data access and authentication services.​
Contract Cryptlets are delegation engines that allows SmartContracts to off-load
computation external to the Ethereum Virtual Machine. Contract Cryptlets can execute on
specialized hardware that can be scaled to achieve necessary performance.

https://github.com/Azure/azure-blockchain-projects/blob/master/bletchley/bletchley-whitepaper.md

Pros
● Handles Byzantine failures. Contract Cryptlets enable scalable off-chain
computations.

Cons
● Proprietary solution designed for the Bletchley platform.
● Contracts must trust external data sources.
Corda Oracles
Corda supports oracle services within the platform.​ Oracles are available during the proposal
and verification stages of a transaction and are either used to attest a ​fact​ made available
within the transaction or to provide (and attest) a facts requested by the transaction. There
are two ways of using oracles in Corda: (1)​ using commands (2) using attachments.
Commands are typically used for data that needs to be obtained on a per transaction basis
(such as current share price) while attachments are useful for reusable data (i.e. the oracle
provides the data once for use in many transactions).

Pros
● Designed into the Corda platform, no need to rely on the third-party implementations.

Cons
● Not reusable across other blockchain implementations.
Town Crier
Town Crier​ was created by students at the Initiative for CryptoCurrencies and Contracts.
(The IC3 is an initiative of faculty members at Cornell University, Cornell Tech, UC Berkeley,
UIUC and the Technion). Town Crier is a data feed system for Smart Contracts that
maintains the authenticity of data that is relayed from external sources (trusted by clients) to
the Smart Contract. It does so by running code in an SGX enclave to retrieve external data
and digitally sign them before returning to the User Contract. The following diagram
illustrates how Town Crier works:

https://eprint.iacr.org/2016/168.pdf

Pros
● Open Source: ​https://github.com/bl4ck5un/Town-Crier​ (implemented in C)
● The components of the TC Server do not need to be trusted as long as the code
running within the enclave is trusted by all parties.
● The Relay can only mount DoS attacks against TC.

Cons
● The solution is designed and implemented for the Ethereum platform.
● Contracts must trust external data sources.
Oraclize
Oraclize is a service that aims to enable smart contracts to access data from other
blockchains and the Internet. The service is currently live on Bitcoin and Ethereum's testnet
and mainnet. It ​offers a provably honest secure retrieval of a webpage by taking advantage
of TLSnotary Proof (a service that allows an auditor to verify if a specific web page was
accurately retrieved).

Pros
● No need to trust the Oraclize service because it provides proof of authenticity of all
data it provides to smart contracts.
● Someone who compromises Oraclize's smart contract doesn't automatically gain the
ability to fake results.
Cons
● If you catch someone faking Oraclize proofs, there's no way to prove it to anyone
else unless ​you yourself​ can obtain the AWS oracle's private key. For further clarity: if
you retrieve some data from Oraclize and it's obviously wrong, there's no way for the
public to know whether the server or the Oraclize service is the source of the
problem.
● Designed for Ethereum, Bitcoin and Rootstock.
● Contracts must trust external data sources.
ChainLInk
ChainLInk is a decentralized public oracle network which uses crypto-economics to
incentivize independent oracle service providers. Each external resources (e.g. data APIs or
payment APIs) are represented by an on-chain ChainLink contract. A user Smart Contract
may select multiple oracle providers to for the same data request in-order to increase trust
on the sourced data. Oracle node providers are paid by LINK tokens for retrieving sourcing
data from external service providers.

Pros
● Implemented as a public blockchain, which yields a decentralised, always-on,
high-speed, censorship-resistant oracle; as a result, no need to create and trust a
centralised service or authority.
● Scalable, with network effects ensuring that additional participants implies better
performance and results.
● Contracts can select multiple oracles, based on reputation, for the same data
request, and validate results to ensure integrity.
Cons
● Requires significant providers for improved security.
● Data privacy concerns for permissioned networks.
Hivemind
Bitcoin Hivemind is a Bitcoin-based, peer-to-peer oracle protocol that uses ​prediction
markets​ to absorb accurate data into a blockchain, offering a scalable, censorship-resistant
and trustless oracle solution implemented as a sidechain of Bitcoin. Hivemind utilises a coin,
VoteCoin, to represent oracle equity. These VoteCoins provide a clear definition of the
concept of “reputation” and makes reputation tradable. Hivemind can host many “branches”,
each of which has its own set of VoteCoins; a higher percentage of VoteCoins owned
implies a greater voting influence within the branch, and a larger share in the branch’s
revenues. VoteCoins are lost if owners refuse to vote, or fail to vote with the plurality;
alternatively, VoteCoins are gained if owners vote on neglected decisions (those with few
votes), or with the plurality.

Pros
● Implemented as a public blockchain, which yields a decentralised, always-on,
high-speed, censorship-resistant oracle; as a result, no need to create and trust a
centralised service or authority.
● Scalable, with network effects ensuring that additional participants implies better
performance and results.
● Utilised Bitcoin smart contracts to automate most of the peer-to-peer Oracle protocol
processes.
Cons
● The solution is designed and implemented as a sidechain of the Bitcoin platform.
● Requires significant users for network effects.
● Data privacy concerns for permissioned networks.