Conference PaperPDF Available

From Oracles to Trustworthy Data On-Chaining Systems



Content may be subject to copyright.
From Oracles to Trustworthy Data
On-chaining Systems
Jonathan Heiss, Jacob Eberhardt, Stefan Tai
Information System Engineering
TU Berlin
Berlin, Germany
Pre-Print Version, ©2019 IEEE. Personal use of this material is permitted. Permission from IEEE must be obtained for all other uses, in any current or future
media, including reprinting/republishing this material for advertising or promotional purposes, creating new collective works, for resale or redistribution to
servers or lists, or reuse of any copyrighted component of this work in other works.
Abstract—Many blockchain transactions require blockchain-
external data sources to provide data. Oracle systems have
been proposed as a link between blockchains and blockchain-
external resources. However, these Oracle systems vary greatly
in assumptions and applicability and each system addresses the
challenge of data on-chaining partly. We argue that Data On-
chaining must be done in a trustworthy manner and, as a first
contribution, define a set of key requirements for Trustworthy
Data On-chaining. Further, we provide an in-depth assessment
and comparison of state-of-the-art Oracle systems with regards
to these requirements. This differentiation pinpoints the need for
a uniform understanding of and directions for future research
on Trustworthy Data On-chaining.
Index Terms—trustworthiness, on-chaining, oracle, smart con-
tract, truthfulness, blockchain, TLS, Trusted Execution Environ-
ment, voting
Blockchains impacted various application domains, ranging
from finance or logistics to digital citizenship and human
rights. They have important new properties, e.g., immutability
and censorship resistance, and enable the decentralized execu-
tion of programs called smart contracts.
No single entity is in control, but a group of independent
peers share the responsibility of operating the network and
processing transactions. Hereby, incentives are designed so
that utility-maximizing network participants pursuing selfish
goals contribute to the network’s overall security. Deviating
from the agreed-on protocol would directly incur financial
losses and is hence neither rational, nor sustainable. Due to
the properties described above, blockchains are commonly
considered to be trustworthy systems, i.e., transactions are
always processed correctly and the results are reliable.
However, for many applications blockchain-internal data
is not sufficient; they require data from blockchain-external
systems like databases or sensors. In this case, the blockchain
needs to rely on data provided by a third party which cannot
be validated within the network. This cannot happen naively;
the data needs to be trustworthy! Otherwise, trustworthiness
of on-chain applications ends when external data becomes part
of transactions.
Various so-called Oracle systems have been proposed,
which aim to provide data to a blockchain in a more reliable
way by incorporating techniques such as advanced cryptogra-
phy [1], trusted execution environments [2], and voting [3]–
However, these systems greatly differ in assumptions and
applicability. They only give attention to specific aspects of
the larger challenge of bringing data to the blockchain in
a trustworthy way. Since the approaches are very different
from each other and vary in their - often narrow - scope and
applicability, they are hard to compare.
To address this shortcoming and provide a conclusive frame-
work, in this paper, we explore and define key properties of
Trustworthy Data On-chaining Systems. In this context, we
make two main contributions:
1) We derive requirements for Trustworthy Data On-
chaining Systems, hereby taking as a holistic view on
the process of bringing data from the blochchain-external
world onto the blockchain. We argue that the established
distributed systems properties of safety and liveness are
not sufficient and propose truthfulness as a third, funda-
mentally critical requirement to adequately characterize
Trustworthy Data On-chaining Systems.
2) We provide an in-depth assessment and comparison of
state-of-the art Oracle approaches with regards to the
criteria for Trustworthy Data On-chaining Systems. This
allows us to identify weaknesses of current approaches
and deduct possibilities for future research.
This paper is organized as follows: In Section II, we
describe the narrow perspective of current Oracle systems and
motivate the need for a more holistic view. We respond to
this problem by introducing Data On-chaining as a compre-
hensive approach for provisioning blockchain-external data
to smart contracts in Section III. In Section IV, we derive
requirements for Trustworthy Data On-Chaining Systems and
identify truthfulness as a fundamentally new requirement.
Taking these results into account, we proceed to categorize and
compare existing oracle implementations, before we discuss
their limitations and applicability in Sections V and VI.
Due to the security guarantees provided by blockchains,
smart contracts are often used to implement critical application
logic. The contracts may require external data as input for
executing on-chain state transitions. However, the involvement
of external data for smart contract computations implies a
risk: data can be unreliable, i.e., unavailable, maliciously mod-
ified, or untruthfully reported. Unreliable data used for smart
contract computations may trigger blockchain transactions
that should not be triggered and, thereby, cause economical
damage, i.e., financial loss. As a consequence, the security
guarantees of the smart contract are devalued and the trust and
the reliability that blockchains are applied for are threatened.
The reliable provisioning of blockchain-external data to
smart contracts has been addressed by a variety of Oracle pro-
posals. Oracles are middleware systems situated at the edge of
the blockchain that intermediate between smart contracts and
external systems. TownCrier [2], for example, is an Oracle that
employs Trusted Execution Environments (TEE) to guarantee
tamper-proof data provisioning for smart contracts. A different
approach is Astraea [3] that introduces game-theoretical mech-
anisms to incentivize truthful provisioning of data. Further,
TLS-N [1] proposes a modification to the Transport Layer
Security (TLS) protocol that allows to prove non-repudiation
of data obtained in TLS sessions to third parties. What those
Oracle proposals all have in common, is the intent to make
off-chain data available to smart contracts in a reliable manner.
These Oracle approaches, however, differ fundamentally in
their system assumptions, trust model, applicability, and in
the specific qualities that they aim to address. For example,
TownCrier [2] and TLS-N [1] address data authenticity and
integrity, whereas Astraea motivates truthful data provisioning.
Further, those approaches take a limited perspective on the
problem of providing unreliable data by focussing only on the
Oracle system component itself and addressing only partial
aspects of the larger challenge of assuring trustworthiness in
Data On-chaining Systems.
The diversity of existing Oracle approaches makes them
hard to compare and to reason about their qualities. To date,
no systematic description of Oracles has been provided that
allows this comparison and supports the design of novel
Data On-chaining is the first concept that approaches the
reliable provisioning of data for smart contracts from a holistic
system perspective. It, hence, allows for comparability of
existing Oracle approaches and paves the way for future
research on Data On-chaining Systems. By addressing the
problem of having unreliable data infiltrate smart contracts
and, hence, devalue the security guarantees provided by the
blockchain, we define Data On-chaining as the reliable provi-
sioning of blockchain-external data to smart contracts in Data
On-chaining Systems which consist of on-chain and off-chain
In contrast to the term Oracle, which takes a narrow view
on the middleware component, Data On-chaining takes an
integrated system perspective comprising all three components
of a Data On-chaining System: the external Data Source, the
Oracle, and Consumer Contract as described in Section III-A.
This extended system perspective helps to raise awareness for
aspects beyond those concerning Oracle exclusively, such as
the availability and truthfulness of Data Sources.
Further, on-chaining complements the term off-chaining
which describes the outsourcing of storage and computation
to non-blockchain systems while preserving the blockchain’s
safety and liveness [7]–[10]. On-chaining takes the opposite
direction and caters for the integration of external resources.
Data On-chaining particularly focusses on providing data.
(a) Consumer Contract and Data Source can connect directly. An
Oracle is not required as the Data Source holds a blockchain account.
(b) The Consumer Contract connects to the blockchain account of the
off-chain Oracle component that in turn connects to the Data Source.
(c) The Consumer Contract connects to an on-chain Oracle compo-
nent that in turn connects to the Data Source’s blockchain account.
(d) The Consumer Contract connects to an on-chain Oracle compo-
nent that communicates with the blockchain account held by the off-
chain Oracle component which in turn connects to the Data Source.
Fig. 1: Data On-chaining System Architectures
A. System Model
Data On-chaining Systems to consist of at least two compo-
nents, the on-chain Consumer Contract and the external Data
Source, and one optional component, the Oracle. Figure 1
summarizes the different architectural compositions of those
components. Implementations of the system architectures de-
picted in Figures 1b, 1c, and 1d are described in Section V.
The Data Source is an off-chain system that is in possession
of the information required by the Consumer Contract. Data
Sources can be of different types, including web-based news
feeds or stock brokers, sensors and devices in the Internet
of Things, but also humans that provide their knowledge
by means of blockchain transactions or web-technologies.
Consumer Contracts may obtain data from multiple Data
Sources directly or indirectly. If a Data Source maintains a
blockchain account, it is able to communicate directly with
Consumer Contracts as shown in Figure 1a. Otherwise an
Oracle is required for intermediation (compare Figures 1b, 1c,
Fig. 2: Requirements for Trustworthy Data On-chaining Systems
The Oracle, as we understand it in Data On-chaining
Systems, is an intermediate system component that bridges
communication between the on-chain Consumer Contract and
the off-chain Data Source. Oracles are not needed for Data On-
chaining if the Data Source maintains a blockchain account as
depicted in Figure 1a. The composition of an Oracle depends
on the capabilities and requirements of Consumer Contracts
and Data Sources: If the Data Source does not maintain a
blockchain account, an off-chain Oracle component is required
as depicted in Figure 1b and 1d. In some cases, an on-chain
Oracle component is required for bridging communication
from off-chain to on-chain as shown in Figure 1c and 1d,.
Depending on the system requirements Consumer Contracts
may employ multiple Oracle and Oracles, in turn, may consult
multiple Data Sources.
The application logic in Data On-chaining Systems is
implemented in one or multiple Consumer Contracts. Con-
sumer Contracts require external data as input for on-chain
state transitions. They can only be addressed via blockchain
transactions and, thus, they can only receive messages from
smart contracts or blockchain accounts maintained by external
entities. Examples for applications of Consumer Contracts
are blockchain-based insurance policies [11]–[13], purchase
management in marketplaces [14]–[17] or goods tracking in
supply chain networks [18], [19]. In the remainder of this
paper, we assume a single Consumer Contract.
As the on-chain component of Oracles and the Consumer
Contract are smart contracts, they are trustworthy, that is, they
are highly available, tamper-proof, and truthful. Being situated
outside the blockchain, the off-chain component of the Oracle
and the Data Source, however, are not trustworthy by default
but vulnerable for failures and attacks.
B. Process Model
In on-chaining systems, data provisioning can be push- and
pull-based. In a pull-based model, the Consumer Contract ex-
plicitly requests data from the Data Source, whereas in a push-
based model, the Data Source provides data without previous
requests. The Oracle forwards data from the Data Source to the
Consumer Contract and, as required in the pull-based model,
the request from Consumer Contract to the Data Source. This
intermediation may involve data and request transformations to
meet the format requirements of Data Sources and Consumer
Contracts. Regardless the initiation of data provisioning, data
has two states while being in the Data On-chaining System.
Data is in transit during transmission, that is, it is sent from
one component to another component. Data is at rest while it
is not in transmission but controlled by one component. Data
becomes part of the on-chaining system once it is received or
recorded by the Data Source. Earlier states are not considered.
Safety and liveness are established properties to characterize
distributed systems for more than 40 years [20]. In the context
of Data On-chaining Systems, safety means that no state
transition of the blockchain is triggered by incorrect data,
whereas liveness means that blockchain state transitions are
never not executed due to unavailable data. However, the
properties safety and liveness do not fully capture the notion
of trustworthiness in blockchain-based systems. As a third
key property for Trustworthy Data On-chaining Systems, we
introduce truthfulness. Truthfulness means that no execution
of blockchain state transition is caused by untruthful data
provisioning, but instead, data is always provisioned in a well
intended way and to the best of the Data Source’s knowledge.
From those three properties for Trustworthy Data On-
chaining Systems, we derive the challenges incentive compat-
ibility,correctness, and availability and introduce associated
requirements that mirror the challenges in more detail. An
overview of the system properties, challenges, and require-
ments is provided in Figure 2.
A. Incentive Compatibility
The novel challenge that derives from truthfulness is incen-
tive compatibility. Incentive compatibility is a system prop-
erty that holds if system components are accountable and
attributable for their actions, i.e., they have something at stake
and the data provisioned as well as changes to the data are
attributable to the originator.
In incentive compatible systems, it is assumed that com-
ponents are homini oeconomici whose primary goal is to
maximize their individual utility. If this economic rational-
ity holds, financial incentives can be placed in a way that
motivates truthful reporting and intermediation of data. Such
incentives are realized by monetary rewards and penalties that
respectively apply for truthful and untruthful data provisioning.
1) Attributability: The data provisioned to the Consumer
Contract must be attributable to the responsible Data Source
and modifications to the data during intermediation must be
attributable to the Oracle.
To apply incentives to Data Sources, it must be possible to
map provisioned data to its provider and, hence, to identify
the Data Source that provisioned data untruthfully. Based on
such an attribution of behavior, Data Sources can be rewarded
and penalized for their actions. The same holds for any data
modifications caused by the Oracle.
2) Accountability: Components in Data On-chaining Sys-
tems must have something at stake that makes them account-
able for truthful data provisioning.
To realize accountability, Data Sources, for example, make
a deposit before providing data. This deposit is payed back if
truthful data provisioning is observed by the system, otherwise
it is slashed. The motivation for Data Sources to provide
data at all, is a reward that is payed out for truthful data
provisioning. The rewards can be enriched with deposits that
are withheld by the system as penalty.
B. Correctness
The challenge that derives from system safety is correctness.
Correctness is defined as a property of data that holds if the
data is authentic and of integrity. The Consumer Contract must
be able to verify that the data obtained really originates from
the specified Data Source and that it has neither maliciously
been modified nor unintentionally been changed. Approaches
to data correctness are discussed in Section V-A, and V-B.
1) Authenticity: The Consumer Contract must be able to
verify the authenticity of data received from the Data Source.
Data authenticity is required to prevent attackers from
triggering unauthorized blockchain transactions by pretending
to be the actual Data Source. As established security problem,
authenticity can be implemented by means of asymmetric
cryptography, such as digital signatures. However, the veri-
fication of the Data Source’s identity is challenging due to
the limited communication capabilities of the smart contracts.
For example, the Consumer Contract cannot simply access
Public Key Infrastructure (PKI) to approve a web-based Data
Source’s identity in form of its public key, but instead requires
support of a trusted intermediary.
2) Integrity: The Consumer Contract must be able to verify
that the data received has not maliciously been tampered with
and has not unintentionally been changed.
Preserving data integrity is important for two reasons. First,
it prevents malicious manipulations of attackers and, second, it
prevents the data from being unintentionally modified through
defectiveness, e.g. caused by malfunctioning communication
channels. Both possibilities have equally drastic consequences
on the safety of the on-chaining system, as critical Consumer
Contract computation may be erroneously triggered. Integrity
needs to be preserved in all cases, that are, data in transit and
data at rest. It can be implemented by means of cryptographic
C. Availability
The challenge that derives from system liveness is availabil-
ity. Availability is defined as a property of data that holds if
it can be accessed whenever access is required. It is achieved
if all components of the on-chaining application are available
and the data maintained by the components are accessible.
1) Component Availability: The off-chain system compo-
nents, Oracle and Data Source, must be designed in a way that
minimizes outages.
As data is replicated on every node in globally distributed
blockchain networks like in Ethereum [21], the blockchain
provides high availability guarantees compared to most non-
blockchain system. The availability of Data On-chaining Sys-
tems, however, is as good as the availability of its least
available component, which is either the off-chain Oracle
component or the Data Source. To compromise the availability
of on-chaining applications as little as possible, it is, hence,
important to minimize the delta between the availability of
the off-chain components and the one of the Consumer Con-
tract. As a consequence, the off-chain components must be
2) Accessibility: Data controlled by the Data Source or
by the Oracle must be accessible in the sense that it can be
provisioned, unrestrictedly and at any time.
The availability of system components does not automati-
cally guarantee availability of the maintained data as the access
to the data can be restricted. In public blockchains, transaction
fees, required to pay the blockchain miners, are carried by the
party that initiates the transactions. In Ethereum, for example,
the costs of transactions are determined by their complexity
and accounted for in an Ethereum-specific unit, called Gas,
which can be purchased for Ether. If smart contracts or external
blockchain account holders in Ethereum-based on-chaining
applications don’t have enough Ether, they cannot submit
transactions and, hence, cannot provide the required data.
Thus, to guarantee accessibility of data in public blockchain-
based Data On-chaining Systems, providing components with
sufficient funds to pay transaction fees is indispensible.
In this section, we now can discuss and differentiate ap-
proaches to Oracles using the requirements that we derived
from the Data On-chaining challenges and system properties.
A. TLS-based Data On-chaining
In TLS-based Data On-chaining, the Transport Layer Secu-
rity (TLS) protocol is instrumented to assure authenticity and
integrity of the data provisioning by the Data Source.
The TLS protocol guarantees message integrity and server
authentication through the exchange of certificates during the
TLS-handshake. The certificate allows clients to validate the
server’s identity by consulting Certificate Authorities that are
part of a Public Key Infrastructure (PKI). As de-facto standard
for secure communication in the internet, TLS is supported by
most web servers, involving millions of potential Data Sources
that are registered in a PKI.
1) Components: The system consists of the Consumer
Contract, an HTTPs-enabled Data Source, and an off-chain
Oracle component (OffOC) as depicted in Figure 3. The Data
Source does not maintain a blockchain account and, thus, an
OffOC is required for intermediation. The data provisioning
model is push-based.
2) Concept: The OffOC and the TLS-enabled server es-
tablish a TLS connection. The integrity and authenticity of
data obtained from the server during this TLS session can be
verified by the OffOC after validating the server’s certificate
with the PKI. If the OffOC is trusted, it signs the data,
transforms it into a blockchain transaction and submits it
to the Consumer Contract as blockchain transaction. The
Consumer Contract then verifies the OffOC’s signature. If the
OffOC is not trusted, it first constructs a proof from the TLS-
session that allows the Consumer Contract to verify integrity
and authenticity of the obtained data with the Data Source’s
certificate. Proof and data are then submitted as blockchain
transaction to the Consumer Contract who verifies authenticity
and integrity using the Data Source’s certificate.
The challenges for TLS-based Data On-chaining are (1) to
construct such a proof and (2) to allow the Consumer Contract
to verify the Data Source’s certificate.
Fig. 3: TLS-based Data On-chaining
3) Implementations: TLS-Notary [22] allows a client to
prove the authenticity and integrity of data obtained from a
server during a TLS session to a specified third party, the
auditor. The auditor must simultaneously be connected to the
client. As currently no smart contract implementation of such
an auditor exist, the auditor cannot be represented by the
Consumer Contract itself, but instead, is represented by a
trusted OffOC. For example, Oraclize [23] applies TLS-Notary
by implementing the auditor on an Amazon EC2 instance and
thereby exploits the reputation of Amazon Web Services as
trusted host. TLS-Notary works as follows: During the TLS
handshake between client and server, the auditor provides the
client with the pre-master secret data required to compute
the master secret, but withholds the part that is needed to
generate the MAC key. Without the MAC key the client cannot
decrypt and authenticate the traffic received from the server.
After the client received encrypted responses to its requests,
it generates a hash from the exchanged traffic and sends it
to the auditor as a commitment to the session. In return, the
client receives the missing part of the pre-master secret from
the auditor which enables decryption and authentication of the
traffic. The TLS-Notary proof consists of the pre-master secret
and the hashed TLS session provided by the client. The pre-
master secret allows the auditor to verify authenticity of the
TLS session. Withholding the MAC key hinders the client to
fake the requested content of the TLS session because it can
neither decrypt the content received, nor can it encrypt a fake
session as the auditor can check the TLS handshake.
TLS-N [1] is a modification to the TLS protocol that over-
comes the requirement of the client in TLS-Notary to connect
to the auditor by generating a non-repudiation proof that can
independently be verified by any third party that has access to
the PKI. This removes the trust assumption from the OffOC.
However, it proposes a modification to the TLS protocol that
is not supported by most public web servers. Further, the
Consumer Contract cannot directly approach the PKI to obtain
the server’s public key, but instead must therefore rely on
a trusted intermediation. In the TLS-N protocol, the server
maintains a state of the TLS session established with the client.
The state consists of a continuously updated hash value of the
exchanged traffic, an ordering vector, and a start timestamp.
Once the client requests the proof, the server signs the state
using its public key and sends it to the client. The proof is
constructed from the session data maintained by the client and
the state that is signed by the server. The client also integrates
the server’s certificate into the proof as well as all ancestor
certificates. This allows any third party that has access to the
PKI to verify the server’s identity by checking its public key.
B. Enclave-based Data On-chaining
Similar to TLS-based Data On-chaining, Enclave-based
Data On-chaining instruments TLS to guarantee data authen-
ticity and integrity. However, to remove the trust assumption
from the Oracle, Trusted Execution Environments (TEE) are
applied that attest data authenticity and integrity to the Con-
sumer Contract.
TEEs provide an execution environment for computations
that is confidential and preserves integrity. Technically, TEEs
are realized as a set of instructions extending the functionality
of a processor with hardware enforced security policies that
protect a dedicated address space against unauthorized access.
To verify the identity of an application that runs inside an
enclave, external parties can consult a Remote Attestation
Service (RAS) that is usually maintained by the manufacturer
of the TEE, e.g. Intel for Intel SGX [24]. Similar to PKIs,
the RAS attests the validity of the enclave’s public key that is
used for message authentication.
1) Components: The system consists of the Consumer
Contract, an HTTPs-enabled Data Source, and an off-chain
Oracle component (OffOC). The Data Source does not hold
a blockchain account and, thus, an OffOC is required for
intermediation. The host that implements the OffOC, however,
runs a TEE that allows to protect critical computation and data
against malicious modifications. The data provisioning model
can be pull- or push-based.
2) Concept: The OffOC establishes a TLS connection to
the Data Source. As first step, integrity and authenticity of the
data obtained in this TLS-session are verified by the OffOC
inside the TEE using TLS capabilities, namely the server’s
certificate and the PKI. As second step, the OffOC signs
the data using the private key that is securely maintained
inside the TEE and forwards the signed data to the Consumer
Contract. The Consumer Contract then verifies the signature
using the public key of the TEE that it reviews in advance
by consulting the RAS. In Enclave-based Data On-chaining,
authenticity and integrity of the Data Source’s messages are
proven in a two-step validation chain, involving TLS-based
verification between the OffOC and the HTTPs-enabled Data
Source as first step, and a digital signature between OffOC
and Consumer Contract as second step.
The challenges for Enclave-based Data On-chaining are to
allow the Consumer Contract to verify (1) the Data Source’s
certificate and (2) the enclave’s public key.
Fig. 4: Enclave-based Data On-chaining
3) Implementation: TownCrier [2] is an Enclave-based Or-
acle that enables pull-based data provisioning and employs
an additional on-chain Oracle that takes requests from the
Consumer Contract and verifies signed data on behalf of
the Consumer Contract. The TEE is implemented using Intel
Software Guard Extensions (SGX) [24] that are built into
specific Intel CPUs and rely on the Intel Attestation Service to
verify the TEE’s identity. As Intel SGX lacks direct network
access, some parts of the OffOC run outside the enclave man-
aging low-level network access. However, critical functionality
including TLS handshakes and all cryptographic operations are
executed inside the enclave to ensure security. To communicate
with the smart contract, the TEE-based OffOC implements a
blockchain client. Due to the requirement of participating in
the consensus protocol, the blockchain client is implemented
outside the enclave but provides an interface to the enclave
to read and write transactions. All messages sent from inside
the enclave are signed by the TEE’s private key to ensure
authenticity and integrity. By using the Intel SGX to secure
critical parts of the TLS-protocol, TownCrier removes the
trust assumption from the OffOC. The Consumer Contract,
however, requires access to the Intel’s Attestation Service
(IAS) to validate the enclave’s identity. This requires trust
in the off-chain IAS infrastructures, which is consulted for
identity verification.
C. Voting-based Data On-chaining
Voting-based Data On-chaining motivates truthful data pro-
visioning of Data Sources that exhibit economically rational
behavior and are incentivized by monetary rewards and penal-
ties to truthfully participate in votes.
Fig. 5: Voting-based Data On-chaining
1) Components: The system consists of the Consumer Con-
tract, multiple Data Sources, and an on-chain Oracle compo-
nent (OnOC) as depicted in Figure 5. The Data Sources main-
tain a blockchain account and submit blockchains transactions
to the OnOC. Consumer Contract and OnOC communicate
on-chain. The data provisioning model is pull-based.
2) Concept: The Consumer Contract submits a data request
to the OnOC in form of a question and thereby initiates a
vote. The OnOC implements all voting logic. The request is
attached with a reward that is paid to the Data Sources that
vote for the right answer. This reward motivates Data Sources
to participate and to truthfully provide data. The right answer
is determined as the one that received most votes. However,
to avoid that all answers are different from each other and
instead facilitate the formation of a majority, the quantity of
possible answers is restricted. For example, the question can
only be answered with yes and no, or with integer values in
the range from 0 to 9. After a specified time-window closes,
the votes are tallied by the OnOC, and the right answer is
determined. The provided reward is split and the shares are
paid to the Data Sources that voted for the right answer.
To strengthen the commitment that Data Sources have to
their vote, a deposit can be demanded from Data Sources for
participation. Deposits are only paid back to the Data Sources
that provide the right answer, otherwise, they are retained and
increase the rewards payable in future voting rounds. Deposits
can also be used for weighted votes. In weighted votes, the
level of the deposit determines the weight that a Data Source
has in the vote and the level of the reward that is emitted if the
right answer is provided. The higher the deposit, the heavier
the weight and the higher rewards and penalties.
To reward continuous truthful participation in votes, the
behavior of the Data Sources can be tracked over the course
of multiple voting rounds and assessed by a reputation value
maintained by the OnOC. The reputation improves if a Data
Source votes for the right answer, whereas it deteriorates if
a false answer is provided. Like deposits, the level of the
reputation value can impact the weight that Data Sources have
in votes and the level of the reward that can be won.
The challenges in Voting-based Data On-chaining are (1)
the right setting of all system parameters including rewards
and deposits and (2) the protection against Sybil [27] and
lazy voting attacks. Lazy voting attacks [3], [4] describe a
situation where voters always vote for the same outcome
refusing truthful data provisioning for the sake of laziness.
3) Implementations: Astraea [3] and Shintaku [4] are
Voting-based Oracle proposals that construct a Nash Equilib-
rium within a set of game-theoretical rules. In both proposals,
true, false, and unknown are the only possible answers.
Astraea [3] proposes a two-part voting scheme. In addition
to the Consumer Contract, called proposer, that publishes data
requests, called propositions, and bounties that are paid for
voting correctly, two types of participants exist: the voters
and the certifiers. Voters and certifiers vote independently from
each other. While voters pay a relatively small deposit to vote
for a proposal to which they are randomly assigned, certifiers
pay a relatively high deposit to vote for a proposition of
their choice. Rewards and penalties are paid according to the
following structure: If voters and certifiers agree, participants
of both types are rewarded if they agree with the majority and
TABLE I: Comparison of Oracle Approaches
Approach Implementation Attributability Accountability Authenticity Integrity Component
Availability Accessibility
TLS-Notary [22] Data Source
is attributable
Components have
nothing at stake
Guaranteed through
Guaranteed through
OffOC is a single
point of failure; data
source availability is
use case dependant
TX carried by OffOC;
OffOC may
withhold data
Data On-chaining
TLS-N [1] Data Source
is attributable
Components have
nothing at stake
Guaranteed through
Guaranteed through
OffOC is a single
point of failure; data
source availability is
use case dependant
TX carried by OffOC;
OffOC may
withhold data
Data On-chaining TownCrier [2] Data Source
is attributable
Components have
nothing at stake
Guaranteed through
TLS, PKI, enclave’s
signature & Remote
Attestation Service
Guaranteed through
TLS, PKI, enclave’s
signature & Remote
Attestation Service
Enclave is a single
point of failure &
Data Source availabity is
use case dependant
TX costs explicitly
reimbursed for
critical components
Astraea [3]
Data sources are
attributable per
voting round
Data Sources are
accountable per round
through deposits
Verifiable on
the blockchain
Guaranteed through
blockchain transactions
Availability depends on
number of participating
Data Sources
Data provisioning
incentivized &
TX costs carried
by Data Source
Shintaku [4]
Data sources are
attributable per
voting round
Data Source are
accountable per round
through deposits
Verifiable on
the blockchain
Guaranteed through
blockchain transactions
Availability depends on
number of participating
Data Sources
Data provisioning
incentivized &
TX costs carried
by Data Source
Data On-chaining
Hivemind [25],
Augur [6]
Data Sources are
attributable across
multiple voting rounds
Data Sources are
accountable across multiple
rounds through financial
stakes in the system
Verifiable on
the blockchain
Guaranteed through
blockchain transactions
Availability depends on
number of participating
Data Sources
Data provisioning
incentivized &
TX costs carried
by Data Source
Chainlink [26]
Data Sources are
attributable across
multiple voting rounds
Data Sources are
accountable across multiple
rounds through financial
stakes and reputation
in the system
Verifiable on
the blockchain
Guaranteed through
blockchain transactions
Availability depends on
number of participating
Data Sources
Data provisioning
incentivized &
TX costs carried
by Data Source
penalized if not. Two reward pools exist for certifiers, one for
true and one for false. Rewards for voters are paid from the
proposition bounty and rewards for certifiers are paid from the
certifiers reward pools. Penalties of both, voters and certifiers,
are funded into the certifiers reward pool of the opposite value
(penalties for incorrect true votes are assigned to the certifiers
reward pool for false votes and vice versa). If voters and
certifiers disagree, certifiers lose all their deposits (paid in
both reward pools equally) but voters are neither rewarded nor
penalized. In this case, the proposer loses its bounty which is
paid equally to both certifier reward pools.
Shintaku [4] proposes a double-voting scheme. Different
from Astraea, in Shintaku all voters are equal. However, voters
pay a deposit which economically commits them to voting for
two propositions to which they are both randomly assigned
in the same voting round. As additional rule, voters may only
receive rewards and penalties if they vote for both propositions
with opposite values (true and false or false and true). If they
do so, voters are independently rewarded and penalized for
each of both assigned votes. If voters provide the same answer
to both propositions, they are neither rewarded nor penalized
and, hence, receive their deposit.
Hivemind [25] and Augur [6] are prediction markets that
apply weighted voting and offer their own tokens for sale
to let participants obtain stake in the system. The amount of
tokens declares how much weight participants have in votes.
In those approaches single nodes report real world events to
decide prediction markets by staking reputation tokens. The
more tokens are at stake, the more difficult it becomes to
challenge the data reported for the market. Only by staking
more tokens than the initial reporters, others can challenge
the report and enter a dispute phase.
Reputation-based votes are realized in ChainLink [26].
ChainLink allows Consumer Contracts acting as clients to
rate the Data Sources based on multiple factors, including
the number of assigned, accepted and completed requests,
the average time to respond and the amount of penalty
payments. ChainLink maintains those reputation ratings and
considers them in the assessment of obtained responses.
Higher reputation values allow for higher rewards and heavier
weight in votes.
A comparison of the approaches and implementations with
regards to the identified requirements for Trustworthy Data
On-chaining is provided in Table I.
TLS-based Data On-chaining focusses on data correctness
and thereby assures authenticity and integrity. The remaining
requirements, however, are neglected. This implies that data
sources can lie and Oracles can withhold data without being
accounted. Also, the availability guarantees are low as the Off-
chain Oracle Component (OffOC) represents a single point
of failure. However, with regards to data correctness, TLS-
based Data On-chaining is especially powerful if a proof can
be constructed from the unmodified TLS protocol that attests
authenticity and integrity to the Consumer Contract. In this
case, the OffOC is not required to be trusted and millions of
Data Sources can securely be accessed.
Enclave-based Data On-chaining addresses data correct-
ness and employs Trusted Execution Environments (TEE) to
remove the need to trust the OffOC. TEEs enable secure
off-chain computation capacities that could, for example, be
used to transform malformed data into the format required
by the Consumer Contract. However, the security assumption
for TEEs is strong and TEEs have been proven vulnerable
[28]–[30]. Also, Remote Attestation Services [24] required to
authenticate the TEE must be trusted.
Voting-based Data On-chaining explicitly addresses in-
centive compatibility by integrating economic rewards and
penalties in the system design. Data availability is high if
the number of Data Sources is high which in turn depends
on the parametrization of the incentive system. As transac-
tions accepted by the blockchain are transparent and tamper-
resistant, the authenticity of transactions submitted by the Data
Sources can be verified and their integrity is guaranteed. With
regards to the requirements for Trustworthy Data On-chaining,
Voting-based Data On-chaining can be evaluated as highly
trustworthy. However, its applicability is strongly restricted
as Data Sources can only confirm information that is publicly
accessible. In cases where specialized data is required that is
held by a single device, Voting-based Data On-chaining is not
In this paper, we introduced Trustworthy Data On-chaining,
a novel holistic perspective on reliable data provisioning for
smart contracts that allows for evaluating existing Oracle
approaches and provides a framework for future designs of
Trustworthy Data On-chaining Systems. Further, we provided
a profound analysis and a detailed comparison of existing Or-
acle approaches with regards to requirements that we derived
from challenges for Trustworthy Data On-chaining.
As the notion of trustworthiness in blockchain-based sys-
tems is not adequately addressed by safety and liveness, we
presented truthfulness as novel property required to charac-
terize Trustworthy Data On-chaining Systems. Truthfulness is
not only important in the context of blockchains, but a generic
requirement for trustworthy systems, e.g., IoT systems that
build on sensor data provided by a group of untrusted entities.
We conclude that future Data On-chaining Systems need
to consider not only safety and liveness, but also truthfulness
from the start and hope to encourage further research on the
open issues current proposals face.
[1] H. Ritzdorf, K. W¨
ust, A. Gervais, G. Felley, and S. Capkun, “TLS-
N: non-repudiation over TLS enablign ubiquitous content signing,” in
NDSS. The Internet Society, 2018.
[2] F. Zhang, E. Cecchetti, K. Croman, A. Juels, and E. Shi, “Town crier: An
authenticated data feed for smart contracts,” in Proceedings of the 2016
ACM SIGSAC Conference on Computer and Communications Security.
ACM, 2016.
[3] J. Adler, R. Berryhill, A. G. Veneris, Z. Poulos, N. Veira, and A. Kas-
tania, “Astraea: A decentralized blockchain oracle,CoRR, 2018.
[4] R. Kamiya, “Shintaku: An end-to-end-decentralized general-purpose
blockchain oracle system,” Available at:
group/paper/blob/master/shintaku.pdf, 2018, acccessed in February
[5] S. Ellis, A. Juels, and S. Nazarov, “Gnosis whitepaper,” Available
DEC2017.pdf, 2017, acccessed in February 2019.
[6] J. Peterson, J. Krug, M. Zoltu, A. K. Williams, and S. Alexander, “Au-
gur: a decentralized oracle and prediction market platform,” Available at:, 2015, acc-
cessed in February 2019.
[7] J.Eberhardt and S.Tai, “On or Off the Blockchain? Insights on Off-
Chaining Computation and Data,” in ESOCC 2017: 6th European
Conference on Service-Oriented and Cloud Computing, 2017.
[8] J. Eberhardt and J. Heiss, “Off-chaining models and approaches to off-
chain computations,” in Proceedings of the 2Nd Workshop on Scalable
and Resilient Infrastructures for Distributed Ledgers, ser. SERIAL’18.
ACM, 2018.
[9] G. Zyskind, O. Nathan, and A. Pentland, “Enigma: Decentralized
computation platform with guaranteed privacy,CoRR, 2015.
[10] A. Kosba, A. Miller, E. Shi, Z. Wen, and C. Papamanthou, “Hawk:
The blockchain model of cryptography and privacy-preserving smart
contracts,” in Security and Privacy (SP), 2016 IEEE Symposium on.
IEEE, 2016, pp. 839–858.
[11] V. Gatteschi, F. Lamberti, C. Demartini, C. Pranteda, and V. Santamar´
“Blockchain and smart contracts for insurance: Is the technology mature
enough?” Future Internet, vol. 10, 2018.
[12] H. T. Vo, L. Mehedy, M. Mohania, and E. Abebe, “Blockchain-based
data management and analytics for micro-insurance applications,” in
Proceedings of the 2017 ACM on Conference on Information and
Knowledge Management, ser. CIKM ’17. ACM, 2017.
[13] “Etherisc,” Available at:, accessed in February
[14] G. Fedak, W. Bendella, and E. Alves, “iexec: Blockchain-based
decentralized cloud computing,” Available at:
content/uploads/pdf/iExec-WPv3.0-English.pdf, 2018, acccessed in
February 2019.
[15] Golem, “Golem project - crowdfunding whitepaper,” Available at:, 2016, acc-
cessed in February 2019.
[16] “Blogpv,” Available at:, accessed in February
[17] M. Klems, J. Eberhardt, S. Tai, S. H¨
artlein, S. Buchholz, and A. Tid-
jani, “Trustless intermediation in blockchain-based decentralized service
marketplaces,” in Service-Oriented Computing - 15th International Con-
ference, ICSOC, 2017.
[18] N. Kshetri, “Can blockchain strengthen the internet of things?” IT
Professional, vol. 19, 2017.
[19] M. Westerkamp, F. Victor, and A. K¨
upper, “Blockchain-based sup-
ply chain traceability: Token recipes model manufacturing processes,”
CoRR, 2018.
[20] L. Lamport, “Proving the correctness of multiprocess programs,” IEEE
Trans. Softw. Eng., 1977.
[21] V. Buterin, “Ethereum: A next-generation smart
contract and decentralized application platform,”,
[22] TLSNotary, “Tlsnotary - a mechanism for independently audited https
sessions,” Available at:, 2014, acc-
cessed in February 2019.
[23] Oraclize, “A scalable architecture for on-demand, untrusted delivery of
entropy,” Available at:, acccessed in February 2019.
[24] Intel, “Innovative Technology for CPU Based Attestation and Seal-
cpu-based-attestation-and-sealing, 2013.
[25] P. Sztorc, “Truthcoin: Peer-to-peer oracle system and prediction mar-
ketplace,” Available at:, 2018, acc-
cessed in February 2019.
[26] S. Ellis, A. Juels, and S. Nazarov, “Chainlink a decentralized oracle
network,” Available at:, 2017,
acccessed in February 2019.
[27] J. R. Douceur, “The sybil attack,” in Peer-to-Peer Systems, P. Druschel,
F. Kaashoek, and A. Rowstron, Eds. Springer Berlin Heidelberg, 2002.
[28] F. Brasser, U. M ¨
uller, A. Dmitrienko, K. Kostiainen, S. Capkun, and
A. Sadeghi, “Software grand exposure: SGX cache attacks are practical,
CoRR, 2017.
[29] M. Schwarz, S. Weiser, D. Gruss, C. Maurice, and S. Mangard, “Mal-
ware guard extension: Using SGX to conceal cache attacks,CoRR, vol.
abs/1702.08719, 2017.
[30] A. Moghimi, G. Irazoqui, and T. Eisenbarth, “Cachezoom: How SGX
amplifies the power of cache attacks,CoRR, vol. abs/1703.06986, 2017.
... To define an appropriate solution (i.e., fulfilling the SDPs' objectives while considering the forces), we went back to the data gathered through identifying and synthesizing challenges and solutions and compared proposed solutions for a given challenge. For example, prior research proposes using the Oracle Pattern whenever external data or realworld data is required by a smart contract [70], [71]. We synthesized information about oracles to come up with a solution for our SDP. ...
... (S.1.1) Off-Ledger Computations: A solution to protect smart contract logic from being visible to all entities with access to the distributed ledger represents the deployment and execution of logic external to the distributed ledger (i.e., off-ledger) using an oracle (see Oracle Pattern) [70], [71]. Upon the invocation of a smart contract function, the smart contract can initiate a call to a service provided by the oracle. ...
... To request external data (e.g., sensor data) or move the execution of computation to oracles [70], [71], [107], smart contracts must interact with oracles. Because of the requirement for determinism in blockchains building on Ethereum and EOSIO (see Table 1), these DLT systems encapsulate smart contract execution in virtual machines (i.e., the EOSVM and EVM) that prevent direct calls to oracles [43]. ...
Full-text available
Smart contracts are a promising means of formalizing and reliably enforcing agreements between entities using distributed ledger technology (DLT). Research has revealed that a significant number of smart contracts are subject to programming flaws, making them vulnerable to attacks and leading to detrimental effects, such as asset loss. Researchers and developers call for a thorough analysis of challenges to identify their causes and propose solutions. To respond to these calls, we conducted two literature reviews and diverse expert interviews and synthesized scattered knowledge on challenges and solutions. We identified 29 challenges (e.g., code visibility, code updateability, and encapsulation) and 60 solutions (e.g., gas limit specification, off-ledger computations, and shadowing). Moreover, we developed 20 software design patterns (SDPs) in collaboration with smart contract developers. The SDPs help developers adjust their programming habits and thus support them in their daily development practices. Our results provide actionable knowledge for smart contract developers to overcome the identified challenges and offer support for comparing smart contract integration concepts across three fundamentally different DLT protocols (i.e., Ethereum, EOSIO, and Hyperledger Fabric). Moreover, we support developers in becoming aware of peculiarities in smart contract development and the resulting benefits and drawbacks.
... Input: The query information set: reqInfo Output: The returned results of querying reqInfo 1 Initialize reference contracts ; 2 Initialize the events of QueryInfoEvent, ToGetInfoEvent, ReturnMessEvent ; 3 for i = 1 to n do 4 if validate(reqInfo) then 5 Receive and process request information ; 6 Emit QueryInfoEvent // emit related events to log 7 Step B; 8 else 9 Return illegitimate warning ; 10 end 11 end 12 while validationParameter(reqInfo) do 13 Transmiting inter-call in the process ; 14 end 15 Step B: 16 if validateParameter(reqInfo) then 17 Instantiate exteranl contract ; 18 Pass parameters and call ; 19 Obtain the result feedback ; ...
... Blockchain oracle is an essential and trusted middleware for access to blockchain and off-chain data. Currently, the trustworthiness of a blockchain oracle is mainly supported by a trusted execution environment or around TLS supplemented with cryptography, including TLS-Notary protocol, TLS-N protocol, etc. [15,19]. Here, we introduce a mixed encryption method combining symmetric and asymmetric keys to secure data with the help of the trusted foundation of a blockchain oracle. ...
Full-text available
Cross-chain interoperability can expand the ability of data interaction and value circulation between different blockchains, especially the value interaction and information sharing between industry consortium blockchains. However, some current public blockchain cross-chain technologies or data migration schemes between consortium blockchains need help to meet the consortium blockchain requirements for efficient two-way data interaction. The critical issue to solve in cross-chain technology is improving the efficiency of cross-chain exchange while ensuring the security of data transmission outside the consortium blockchain. In this article, we design a cross-chain architecture based on blockchain oracle technology. Then, we propose a bidirectional information cross-chain interaction approach (CCIO) based on the former architecture, we novelly improve three traditional blockchain oracle patterns, and we combine a mixture of symmetric and asymmetric keys to encrypt private information to ensure cross-chain data security. The experimental results demonstrate that the proposed CCIO approach can achieve efficient and secure two-way cross-chain data interactions and better meet the application needs of large-scale consortium blockchains.
... Fig. 1 shows a brief overview of the interactions between parties. Here, sensed data m i from an IIoT device is encrypted and sent to fog node F. In this context, a couple of works [41,42] have proposed solutions to securely migrate data from external sources (e.g. IoT devices) to the blockchain network. ...
... It is quite logical that in such a scenario, fog being less resource-constrained will perform the necessary interactions with the blockchain. Hence, unlike [41,42], there are no direct interactions between the IIoT devices and the blockchain in our proposal as shown in Fig. 1. However, all necessary measures (e.g. ...
Industrial Internet of Things (IIoT) opens up a challenging research area towards improving secure data sharing which currently has several limitations. Primarily, the lack of inbuilt guarantees of honest behavior of participating, such as end-users or cloud behaving maliciously may result in disputes. Given such challenges, we propose a fair, accountable, and secure data sharing scheme, FairShare for IIoT. In this scheme, data collected from IoT devices are processed and stored in cloud servers with intermediate fog nodes facilitating computation. Authorized clients can access this data against some fee to make strategic decisions for improving the operational services of the IIoT system. By enabling blockchain, FairShare prevents fraudulent activities and thereby achieves fairness such that each party gets their rightful outcome in terms of data or penalty/rewards while simultaneously ensuring accountability of the services provided by the parties. Additionally, smart contracts are designed to act as a mediator during any dispute by enforcing payment settlement. Further, security and privacy of data are ensured by suitably applying cryptographic techniques like proxy re-encryption. We prove FairShare to be secure as long as at least one of the parties is honest. We validate FairShare with a theoretical overhead analysis. We also build a prototype in Ethereum to estimate performance and justify comparable results with a state-of-the-art scheme both via simulation and a realistic testbed setup. We observe an additional communication overhead of 256 bytes and a cost of deployment of 1.01 USD in Ethereum which are constant irrespective of file size.
... However, existing research on blockchain-based DTs has focused on the datasharing capabilities [3,7], or the use of Blockchain as an enabler for additive manufacturing [8]. Consequently, the role of the IoT sensors as secure, trustworthy data sources for the DTs is still an issue that needs to be addressed [9]. In this perspective, we propose SmartTwin as an architecture to enable the integration of IoT and blockchain technology to create blockchain-based DTs. ...
... In the proposed architecture, sensing devices are direct actors on the blockchain system, have a unique blockchain identity, and generate digitally signed transactions. The use of cryptography at the core of the architecture aligns with the current security challenges in IoT and guarantees a root of trust for the sensed data, bringing the IoT devices a step closer to trustworthy blockchain oracles [9]. ...
A Digital Twin provides a virtual representation of a physical object, complementing theoretical models with real-world data provided by the Internet of Things. Currently, most cloud-based IoT platforms provide device virtualization with different levels of detail and complexity. Nonetheless, this approach has inherited the disadvantages and risks of cloud computing, such as centralizing and isolating the information. Thus, a blockchain-based Digital Twin could provide a unique combination of properties to address these challenges while ensuring availability, integrity, and confidentiality. Current research on blockchain-based Digital Twin has focused on the data-sharing functionalities. However, the role of the IoT sensors as secure, trustworthy data sources is still an issue that needs to be addressed in the Digital Twin domain. In this work, we propose SmartTwin as a software framework to develop blockchain-based Digital Twins. The architecture’s key is considering IoT as direct actors on the blockchain system, taking advantage of the cryptographic capabilities of Blockchain to create a root-of-trust for the data feeding the Digital Twin. In addition, our proposal uses smart contracts as a software platform to define complex business logic. Finally, to illustrate the benefits of SmartTwin, we describe two use cases where the framework was used.KeywordsBlockchainDigital twinInternet of thingsSmart contracts
... Yet, to perform its task, the proposed scheme covers components in both the on-chain and off-chain world. For these reasons, we have opted for the oracle concept [33] as an alternative to request identity data from external parties. As a matter of fact, to interact with outside sources (IdPs and SPs) during Attribute Aggregation and the membership process, the suggested paradigm relies on a pool of oracles that fetch data from the outside world onto the federated Blockchain. ...
Full-text available
The Identity Federation has been introduced as an appropriate solution to overcome cybersecurity risks via a reliable management of users identities, while enhancing usability, security, and privacy aspects. However, the interoperability has become one of the greatest challenges facing typical Identity Federations. Simultaneously, the centralization approach of the trust management in current Identity Federations is another major concern, leading to inherent deficiencies such as a central point of failure and scalability issues. In order to better deal with such a dilemma, we present in this paper an innovative framework of Attribute Aggregation within a federated Blockchain, by overcoming the major challenges related to the interoperability requirement and trust management that could reduce the attractiveness of the Identity Federation approach. The proposed system is relied mainly on the SAML standard and Smart Contracts. The experimental results show the efficiency of Fedidchain compared to centralized models of Attribute Aggregation within Identity Federations.
... The deposit of collateral has been proposed to incentivize honest behavior in permissionless notary networks [42]. Oracle implementations such as Astrea [43] or ChainLink [44] permit arbitrary participants to join the network by depositing some collateral. ...
Full-text available
Most current cross-blockchain approaches focus on exchanging or transferring tokens between networks. While some concepts foster smart contract invocations across blockchains, they require multiple transactions and operate asynchronously. We present a concept enabling instant smart contract calls by creating synchronized client contracts on arbitrary blockchains. Other smart contracts can query these client contracts on the target blockchain for retrieving information without requiring cross-chain message queues. With this, we reduce the dependency of smart contracts on their host blockchain, as remote contracts become available as read-only instances. The synchronization process does not require trust in the executing intermediary since Merkle proofs based on shared state roots are utilized to guarantee correct execution. We propose a novel concept called transition proofs for efficiently proving the correctness of state updates. The prototypical implementation permits smart contract synchronization between EVM-compatible blockchains. Our evaluation shows the approach’s applicability regarding execution costs and delay. Further, we conduct a case study by synchronizing one of the largest decentralized exchanges deployed to the Ethereum network.
... The purpose was to publicly verify data feeds on the main consensus chain. Heiss et al. [10] enforce the need to ensure trust worthy on-chain data and then propose a set of rules to be implemented in oracles in accordance with the trust worthy on-chain data. Schaad et al. [11] implemented a hardware-based oracle (printer in that case) using existing software level protection scheme. ...
The core of blockchain smart contracts is the execution of business logic code in a decentralized architecture with all executing nodes trusting and agreeing on the results. Smart contracts are unable to get data from the outside world on their own. Smart contracts communicate with oracles, which are off-chain data sources whose primary function is to collect and give data feeds to smart contracts. The usage of oracle returns the blockchain to its centralization problem and also exposes the blockchain to the possibility of introducing corrupt, malicious and erroneous data. This problem is called ‘Oracle problem’. This paper presents an investigation of this problem. To demonstrate this, we have considered the price oracle problem using chainlink’s decentralized network of nodes that connects off-chain data to on-chain smart contracts through oracles. Finally, we performed an analysis and comparison on retrieving external off-chain data through external APIs (Application Programming Interfaces) and through decentralized oracles. This would be helpful in determining how decentralization (through oracles) may result in performance constraints in contrast to fetching data through our own built APIs where data source APIs of blockchain are not connected to the decentralized nodes of network. The results have shown the increase in transaction throughput of the overall system.
The financial crisis of 2008 breached society’s trust in banks and centralized financial institutions. Bitcoin appeared as a response to those transgressions, proving that the blockchain technology it implements is reliable. Since then, this technology has become widespread in the form of new cryptocurrencies and an increasing number of people have begun to invest in them. In the absence of a body to regulate the cryptocurrency market, users play with and encourage the fluctuations in their price, causing them to be treated as investment assets rather than transaction assets. This work carries out and then discusses a systematic study of the state of the art and of the general challenges faced by cryptocurrencies.KeywordsCryptocurrenciesSystematic reviewChallenges
This chapter focuses on the emerging field of robonomics , which studies the sociotechnical impact of blockchain technologies on social human–robot interaction, behavioral economics, behavioral game theory, and cryptocurrencies for the social integration of robots into human society. Advanced blockchain technologies such as oracles enable the on‐chaining of blockchain‐external off‐chain information stemming from human users. In doing so, they leverage on human intelligence rather than machine learning only. The chapter also investigates the widely studied trust game of behavioral economics in a blockchain context, paying close attention to the importance of developing efficient cooperation and coordination technologies. It then elaborates on the shift from conventional monetary economics to nonmonetary tokenomics enabled by tokenization in different value‐based scenarios. In conventional economics, innovation proceeds and propagates by introducing a change in the context of set rules and by observing how such a relatively rigid framework reacts to the change.
Smart contracts, that allow parties to establish agreements based on predefined rules without a trusted third-party, have been explored in various applications. However, the main drawback of smart contracts is that they cannot access the external data required to trigger the execution of inner logic. The Oracle technology is an interactive bridge between on-chain smart contracts and off-chain data, which is designed to introduce external data into the blockchain system. A superior oracle mechanism should achieve reliable data acquisition with easy data parsing, deployable services, high system efficiency, and cost-effectiveness. The current smart contracts oracle mechanisms either rely on a trusted third-party or introduce high computation overhead and difficulty in deployment. This paper, for the first time, proposes a decentralized and efficient on-chain oracle mechanism CCOM. In our scheme, a prisoner’s contract is introduced for users who want to obtain specific information. The user introduces two oracles to complete the same task of obtaining data, and the contract can prevent oracles from collusion. Rational oracles will not collude but honestly submit the correct result to increase self-interest. We also demonstrate that the proposed scheme can resist a single potentially malicious oracle service and prevent collusion from occurring. Finally, we perform experiments on Ethereum test network Rinkeby and show that our scheme is time-efficient and cost-effective.KeywordsOracleSmart contractCollusion-resistantGame theory
Full-text available
In modern computer systems, user processes are isolated from each other by the operating system and the hardware. Additionally, in a cloud scenario it is crucial that the hypervisor isolates tenants from other tenants that are co-located on the same physical machine. However, the hypervisor does not protect tenants against the cloud provider and thus, the supplied operating system and hardware. Intel SGX provides a mechanism that addresses this scenario. It aims at protecting user-level software from attacks from other processes, the operating system, and even physical attackers.In this paper, we demonstrate fine-grained software-based side-channel attacks from a malicious SGX enclave targeting co-located enclaves. Our attack is the first malware running on real SGX hardware, abusing SGX protection features to conceal itself. Furthermore, we demonstrate our attack both in a native environment and across multiple Docker containers. We perform a Prime+Probe cache side-channel attack on a co-located SGX enclave running an up-to-date RSA implementation that uses a constant-time multiplication primitive. The attack works, although in SGX enclaves, there are no timers, no large pages, no physical addresses, and no shared memory. In a semi-synchronous attack, we extract 96 % of an RSA private key from a single trace. We extract the full RSA private key in an automated attack from 11 traces within 5 min.
Conference Paper
Full-text available
Growing consumer awareness as well as manufac-turers' internal quality requirements lead to novel demands on supply chain traceability. Existing centralized solutions suffer from isolated data storage and lacking trust when multiple parties are involved. Decentralized blockchain-based approaches attempt to overcome these shortcomings by creating digital representations of physical goods to facilitate tracking across multiple entities. However, they currently do not capture the transformation of goods in manufacturing processes. Therefore, the relation between ingredients and product is lost, limiting the ability to trace a product's provenance. We propose a blockchain-based supply chain traceability system using smart contracts. In such contracts, manufacturers define the composition of products in the form of recipes. Each ingredient of the recipe is a non-fungible token that corresponds to a batch of physical goods. When the recipe is applied, its ingredients are consumed and a new token is produced. This mechanism preserves the traceability of product transformations. The system is implemented for the Ethereum Virtual Machine and is applicable to any blockchain configuration that supports it. Our evaluation reveals that the gas costs scale linearly with the number of products considered in the system. This leads to the conclusion that the solution can handle complex use cases.
Full-text available
Blockchain is receiving increasing attention from academy and industry, since it is considered a breakthrough technology that could bring huge benefits to many different sectors. In 2017, Gartner positioned blockchain close to the peak of inflated expectations, acknowledging the enthusiasm for this technology that is now largely discussed by media. In this scenario, the risk to adopt it in the wake of enthusiasm, without objectively judging its actual added value is rather high. Insurance is one the sectors that, among others, started to carefully investigate the possibilities of blockchain. For this specific sector, however, the hype cycle shows that the technology is still in the innovation trigger phase, meaning that the spectrum of possible applications has not been fully explored yet. Insurers, as with many other companies not necessarily active only in the financial sector, are currently requested to make a hard decision, that is, whether to adopt blockchain or not, and they will only know if they were right in 3–5 years. The objective of this paper is to support actors involved in this decision process by illustrating what a blockchain is, analyzing its advantages and disadvantages, as well as discussing several use cases taken from the insurance sector, which could easily be extended to other domains.
Conference Paper
Full-text available
The potential for blockchains to fundamentally transform how organizations produce and capture value is huge and very real. Practical applications dealing with nearly any type of digital asset demonstrate this capacity. Blockchain-based application architectures benefit from a set of unique properties including immutability and transparency of cryptographically-secured and peer-recorded transactions, which have been agreed upon by network consensus. Blockchain-based applications, however, may also suffer from high computational and storage expenses, negatively impacting overall performance and scalability. In this paper, we report on lessons learned and insights gained from a set of experimental blockchain projects, focusing on off-chaining: How to move computation and data off-the-chain, without compromising the properties introduced and benefits gained by using blockchains in the first place.
Conference Paper
Off-chaining has been suggested to enhance scalablity and privacy of blockchains, especially in public networks. However, a systematic classification is missing. In this paper, we propose generic off-chaining models categorizing different types of off-chaining. From our analysis of these models, we conclude that off-chain computations are particularly powerful and subsequently provide a description and comparison of off-chain computation approaches.
Conference Paper
In this paper, we demonstrate a blockchain-based solution for transparently managing and analyzing data in a pay-as-you-go car insurance application. This application allows drivers who rarely use cars to only pay insurance premium for particular trips they would like to travel. One of the key challenges from database perspective is how to ensure all the data pertaining to the actual trip and premium payment made by the users are transparently recorded so that every party in the insurance contract including the driver, the insurance company, and the financial institution is confident that the data are tamper-proof and traceable. Another challenge from information retrieval perspective is how to perform entity matching and pattern matching on customer data as well as their trip and claim history recorded on the blockchain for intelligent fraud detection. Last but not least, the drivers' trip history, once have been collected sufficiently, can be much valuable for the insurance company to do offline analysis and build statistics on past driving behaviour and past vehicle runtime. These statistics enable the insurance company to offer the users with transparent and individualized insurance quotes. Towards this end, we develop a blockchain-based solution for micro-insurance applications that transparently keeps records and executes smart contracts depending on runtime conditions while also connecting with off-chain analytic databases.
Conference Paper
Service marketplaces promise an open platform for sellers and buyers of IT services. The marketplace design usually assumes that market functions, such as match-making, transaction settlement, and dispute resolution are performed by intermediaries in a centralized system. We propose the concept of trustless intermediation to enable new forms of decentralized service marketplaces. By leveraging blockchain-enabled smart contracts we eliminate the need for trust in marketplace intermediaries and reduce barriers of entry, lock-in, and transaction costs, by removing now obsolete trust-establishing mechanisms. Desema, our decentralized service marketplace prototype, is a first implementation of this concept that is based on the Ethereum blockchain in combination with IPFS, a peer-to-peer distributed file system.